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CHAPTER  1 
INTRODUCTION 


The  Ada  inplementation  described  above  was  tested  according  to  the  Ada 
Validation  Procedures  [Pro90]  against  the  Ada  Standard  [Ada83]  using  the 
current  Ada  Con^iler  Validation  Capability  (ACVC) .  This  Validation  Summary 
Report  (VSR)  gives  an  account  of  the  testing  of  this  Ada  implementation. 

For  any  technical  terms  used  in  this  report,  the  reader  is  referred  to 
[Pro90] .  A  detailed  description  of  the  ACVC  may  be  found  in  the  current 
ACVC  User's  Guide  (UG89] . 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada 
Certification  Body  may  make  full  and  free  public  disclosure  of  this  report. 
In  the  United  States,  this  is  provided  in  accordance  with  the  "Freedom  of 
Information  Act"  (5  U.S.C.  #552).  The  results  of  this  validation  apply 
only  to  the  computers,  operating  systems,  and  costlier  versions  identified 
in  this  report . 

The  organizations  represented  on  the  signature  page  of  this  report  do  not 
represent  or  warrant  that  all  statements  set  forth  in  this  report  are 
accurate  ahcf  complete,  or  that  the  subject  Isplementation  has  no 
nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of 
this  report  are  available  to  the  public  from  the  AVF  which  performed  this 
validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 

Questions  regarding  this  report  or  the  validation  test  results  should  be 
directed  to  the  AVF  which  performed  this  validation  or  to: 

Ada  Validation  Organization 

Computer  and  Software  Engineering  Division 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria  VA  22311-1772 
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1.2  REFERENCES 

[Ada83]  Reference  Manual  for  the  Ada  Programming  Language, 

ANSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1987. 

[Pro90]  Ada  Con^ller  Validation  Procedures,  Version  2.1,  Ada  Joint 
Program  Office,  August  1990. 

[UG89]  Ada  Con^iler  Validation  Capability  User's  Guide,  21  June  1989. 


1.3  ACVC  TEST  CLASSES 

Conpliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC.  The  ACVC 
contains  a  collection  of  test  programs  structured  into  six  test  classes:  A, 
B,  C,  D,  E,  and  L.  The  first  letter  of  a  test  name  identifies  the  class  to 
which  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executable.  Class  B  and 
class  L  tests  are  exp>ected  to  produce  errors  at  compile  time  and  link  time, 
respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and  produce  a 
PASSED,  FAILED,  or  NOT  APPLICABLE  message  indicating  the  result  when  they 
are  executed.  Three  Ada  library  units,  the  packages  REPORT  and  SPPRT13, 
and  the  procedure  CHECK_FILE  are  used  for  this  purpose.  The  package  REPORT 
also  provides  a  set  of  identity  functions  used  to  defeat  some  conpiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test 
objective.  The  package  SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the 
Ada  Standard.  The  procedure  CHECK_FILE  is  used  to  check  the  contents  of 
text  files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  the  Ada 
Standard.  The  operation  of  REPORT  and  CHECK_FILE  is  checked  by  a  set  of 
executable  tests.  If  these  units  are  not  operating  correctly,  validation 
testing  is  discontinued. 

Class  B  tests  check  that  a  compiler  detects  illegal  language  usage.  Class 
B  tests  are  not  executable.  Each  test  in  this  class  is  compiled  and  the 
resulting  conqpilation  listing  is  examined  to  verify  that  all  violations  of 
the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada 
code  which  must  not  be  flagged  illegal  by  the  conpller.  This  behavior  is 
also  verified. 

Class  L  tests  check  that  an  Ada  implementation  correctly  detects  violation 
of  the  Ada  Standard  involving  multiple,  separately  con^iled  units.  Errors 
are  expected  at  link  time,  and  execution  is  attempted. 

In  some  tests  of  the  ACVC,  certaacro  strings  have  to  be  replaced  by 
inplementation-specific  values  —  for  exan^le,  the  largest  integer.  A  list 
of  the  values  used  for  this  implementation  is  provided  in  Appendix  A.  In 
addition  to  these  anticipated  test  modifications,  additional  changes  may  be 
required  to  remove  unforeseen  conflicts  between  the  tests  and 
iiqplementation-dependent  characteristics.  The  modifications  required  for 
this  implementation  are  described  in  section  2.3. 
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For  each  Ada  implementation,  a  customized  test  suite  is  produced  by  the 
AVF.  This  customization  consists  of  making  the  modifications  described  in 
the  preceding  paragraph,  removing  withdratm  tests  (see  section  2.1),  and 
possibly  removing  some  inapplicable  tests  (see  section  2.2  and  [UG89]). 

In  order  to  pass  an  ACVC  an  Ada  inqplementation  must  process  each  test  of 
the  customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 

Ada  Con^iler  The  software  and  any  needed  hardware  that  have  to  be  added 
to  a  given  host  and  target  con^uter  system  to  allow 
transformation  of  Ada  programs  into  executable  form  and 
execution  thereof.  _  . 

Ada  Compiler  The  means  for  testing  compliance  of  Ada  implementations. 
Validation  consisting  of  the  test  suite,  the  support  programs,  the  ACVC 
Capability  user's  guide  and  the  tenplate  for  the  validation  summary 
(ACVC)  report. 

Ada  An  Ada  conpiler  with  its  host  computer  system  and  its 

Inplementation  target  conputer  system. 

Ada  Joint  The  part  of  the  certification  body  which  provides  policy  and 

Program  guidance  for  the  Ada  certification  system. 

Office  (AJPO) 

Ada  The  part  of  the  certification  body  which  carries  out  the 

Validation  procedures  required  to  establish  the  cottpliance  of  an  Ada 
Facility  (AVF)  implementation. 

Ada  The  part  of  the  certification  body  that  provides  technical 

Validation  guidance  for  operations  of  the  Ada  certification  system. 

Organization 
(AVO) 

Compliance  of  The  ability  of  the  implementation  to  pass  an  ACVC  version, 
an  Ada 

Implementation 

Computer  A  functional  unit,  consisting  of  one  or  more  computers  and 

System  associated  software,  that  uses  common  storage  for  all  or 

part  of  a  program  and  also  for  all  or  part  of  the  data 
necessary  for  the  execution  of  the  program;  executes 
user-written  or  user-designated  programis;  performs 
user-designated  data  manipulation,  including  arithmietic 
operations  and  logic  operations;  and  that  can  execute 
programs  that  modify  themselves  during  execution.  A 
computer  system  may  be  a  stand-alone  unit  or  miay  consist  of 
several  inter-connected  units. 
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Conformity 


Customer 


Declaration  of 
Conformance 


Host  Computer 
System 

Inapplicable 

test 

ISO 

LRM 


Operating 

System 


Target 

Con^uter 

System 

Validated  Ada 
Compiler 

Validated  Ada 
Implementat ion 

Validation 


Withdravm 

test 


Fulfillment  by  a  product,  process,  or  service  of  all 
requirements  specified. 

An  individual  or  corporate  entity  who  enters  into  an 
agreement  with  an  AVF  which  specifies  the  terms  and 
conditions  for  services  (of  any  kind)  to  be  performed. 

A  formal  statement  from  a  customer  assuring  that  conformity 
is  realized  or  attainable  on  the  Ada  implementation  for 
which  validation  status  is  realized. 

A  computer  system  where  Ada  source  programs  are  transformed 
into  executable  form. 

A  test  that  contains  one  or  more  test  objectives  found  to  be 
irrelevant  for  the  given  Ada  ia^lementation. 

International  Organization  for  Standardization. 

The  Ada  standard,  or  Language  Reference  Manual,  published  as 
ANSI/MIL-STD-181SA-1983  and  ISO  8652-1987.  Citations  from 
the  LRM  take  the  form  "<sectlon>.<subsection>:<paragraph>.'' 

Software  that  controls  the  execution  of  programs  and  that 
provides  services  such  as  resource  allocation,  scheduling, 
input/output  control,  and  data  management.  Usually, 
operating  systems  are  predominantly  software,  but  partial  or 
conplete  hardware  implementations  are  possible. 

A  computer  system  where  the  executable  form  of  Ada  programs 
are  executed. 


The  compiler  of  a  validated  Ada  implementation. 


An  Ada  inplementation  that  has  been  validated  successfully 
either  by  AVF  testing  or  by  registration  [Pro90] . 

The  process  of  checking  the  conformity  of  an  Ada  conpiler  to 
the  Ada  programming  language  and  of  issuing  a  certificate 
for  this  inplementation. 

A  test  found  to  be  incorrect  and  not  used  in  conformity 
testing.  A  test  may  be  Incorrect  because  it  has  an  invalid 
test  objective,  fails  to  meet  its  test  objective,  or 
ains  erroneous  or  illegal  use  of  the  Ada  programming 
language . 
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CHAPTER  2 

IMPLEMENTATION  DEPENDENCIES 


2.1  WITHDRAWN  TESTS 

The  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for 
withdrawing  each  test  Is  available  from  either  the  AVO  or  the  AVF.  The 
publication  date  for  this  list  of  wlthdra%m  tests  Is  2  August  1991. 

E28005C  B28006C  C32203A  C34006D  C35508I  C35508J  C35508M  C35508N 
C35702A  C35702B  B41308B  C43004A  C45114A  C45346A  C45612A  C45612B 
C45612C  C45651A  C46022A  B49008A  B49008B  A74006A  C74308A  B83022B 
B83022H  B83025B  B83025D  C83026A  B83026B  C83041A  B85001L  C860O1F 
C94021A  C97116A  C98003B  BA2011A  CB7001A  CB7001B  CB7004A  CC1223A 
BC1226A  CC1226B  BC3009B  BD1B02B  BD1B06A  AD1B08A  BD2A02A  CD2A21E 
CD2A23E  CD2A32A  CD2A41A  CD2A41E  CD2A87A  CD2B1SC  BD3006A  BD4008A 
CD4022A  CD4022D  CO4024B  CD4024C  CD4024D  CD4031A  CD4051D  CD5111A 
CD7004C  ED7005D  CD7005E  AD7006A  CD7006E  AD7201A  AD7201E  CD7204B 
AD7206A  BD8002A  B08004C  CD9005A  CD9005B  CDA201E  CE2107I  CE2117A 
CE2117B  CE2119B  CE2205B  CB2405A  CE3111C  CE3116A  CB3118A  CE3411B 
CE3412B  CE3607B  CZ3607C  CE3607D  CE3812A  CE3814A  CE3902B 


2,2  INAPPLICABLE  TESTS 

A  test  is  Inapplicable  If  It  contains  test  objectives  which  are  Irrelevant 
for  a  given  Ada  Implementation.  Reasons  for  a  test's  Inapplicability  may  be 
supported  by  documents  Issued  by  ISO  and  the  AJPO  known  as  ^proved  Ada 
Commentaries  and  commonly  referenced  in  the  format  Al-ddddd.  For  this 
In^lementatlon,  the  following  tests  were  determined  to  be  inapplicable  for 
the  reasons  Indicated;  references  to  Ada  Coimnentarles  are  Included  .as 
appropriate. 


The  following  201  tests  have  floating-point  type  declarations 
requiring  more  digits  than  SYSTEM. MAX_DIGITS  : 

C24113L..Y  C35705L,.Y  C35706L. .Y  C35707L. ,Y  C35708L. .Y  C35802L. .Z 
C45241L..Y  C45321L.,Y  C45421L..Y  C45521L..Z  C45524L..Z  C45621L..Z 
C45641L..Y  C46012L..Z 

The  following  20  tests  check  for  predefined  type  LONG_INTEGER;  for 
this  Inplementatlon,  there  Is  no  such  type: 

C35404C  C45231C  C45304C  C45411C  C45412C  C45502C  C45503C  C45504C 
C45504F  C45611C  C45613C  C45614C  C45631C  C45632C  B52004D  C55B07A 
B55B09C  B86001W  C86006C  CD7101F 

C35713D  B86001Z  check  for  a  predefined  floating-point  type  with  a  name 
other  than  FLOAT,  SHORT_FLOAT  or  LONG_FLOAT;  for  this  Inplementatlon, 
there  Is  no  such  type. 
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C45531M. .P  (4  tests)  and  C45532M. .P  (4  tests)  chec]c  fixed-point 
operations  for  types  that  require  a  SYSTEM. MAX_MANTISSA  of  47  or 
greater;  for  this  implementation,  MAX_MANTISSA  is  less  than  47. 

C4S536A,  C46013B,  C46031B,  C46033B,  and  C46034B  contain  length  clauses 
that  specify  values  for  'SMALL  that  are  not  powers  of  two  or  ten;  this 
implementation  does  not  support  such  values  for  'SMALL. 

C45624A..B  (2  tests)  chec)c  that  the  proper  exception  is  raised  if 
MACHINE_0VERFL0WS  Is  FALSE  for  floating  point  types  and  the  results  of 
various  floating-point  operations  lie  outside  the  range  of  the  base 
type;  for  this  implementation,  MACHINE_OVERFLOWS  is  TRUE. 

B86001Y  uses  the  name  of  a  predefined  fixed-point  type  other  than  type 
DURATION;  for  this  implementation,  there  is  no  such  type. 

C96005B  uses  values  of  type  DURATION'S  base  type  that  are  outside  the 
range  of  type  DURATION;  for  this  implementation,  the  ranges,  are  the 
san»e.  ~  ' 


CD1009C  checks  whether  a  length  clause  cat.  specify  a  non-default  size 
for  a  floating-point  type;  this  implementation  does  not  support  such 
sizes. 

CD2AS3A  checks  operations  of  a  fixed-point  type  for  which  a  length 
clause  specifies  a  power-of-ten  TYPE 'SMALL;  this  implementation  does 
not  support  decimal  'SMALLs.  (See  section  2.3.) 

CD2A84A,  C02A84E,  CD2A84I..J  (2  tests),  and  CD2A840  use  length  clauses 
to  specify  non-default  sizes  for  access  types;  this  Implemientation 
does  not  support  such  sizes. 

BD8001A,  BD8003A,  BD8004A. .B  (2  tests),  and  AD8011A  use  machine  code 
insertions;  this  implementation  provides  no  package  MACHINE_CODE. 
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The  tests  listed  In  the  following  table  check  that  USE_ERROR  is  raised 
if  the  given  file  operations  are  not  supported  for  the  given 
combination  of  mode  and  access  method;  this  isplementation  supports 
these  operations. 


Test  File  Operation 

Mode 

File  Access  Method 

CE2102E 

CREATE 

OUT  FILE 

SEQUENTIAL  10 

CE2102F 

CREATE 

INOUT  FILE 

DIRECT  10 

CE2102J 

CREATE 

OUT  FILE 

DIRECT  10 

CE2102N 

OPEN 

IN  FILE 

SEQUENTIAL  10 

CE2102O 

RESET 

IN  FILE 

SEQUENTIAL  10 

CE2102P 

OPEN 

OUT  FILE 

SEQUENTIAL  10 

CE2102Q 

RESET 

OUT  FILE 

SEQUENTIAL  10 

CE2102R 

OPEN 

INOUT  FILE 

DIRECT  10 

CE2102S 

RESET 

INOUT  FILE 

DIRECT  10 

CE2102T 

OPEN 

IN  FILE 

DIRECT  10 

CE2102U 

RESET 

IN  FILE 

DIRECT  10 

CE2102V 

OPEN 

OUT  FILE 

DIRECT  10 

CE2102W 

RESET 

OUT  FILE 

DIRECT  10 

CE3102F 

RESET 

Any  Mode 

TEXT  10 

CE3102G 

DELETE 

Any  Mode 

TEXT  10 

CE3102I 

CREATE 

OUT  FILE 

TEXT  10 

CE3102J 

OPEN 

IN  FILE 

TEXT  10 

CE3102K 

OPEN 

OUT  FILE 

TEXT  10 

The  tests  listed  in  the  following  table  are  not  apolicable  because  the 
given  file  operations  are  not  supported  for  the  given  combination  of 
mode  and  file  access  method. 

Test  File  Operation  Mode  File  Access  Method 


CE2105A  CREATE  IN_FILE  SEQUENTIAL_IO 

CE2105B  CREATE  IN_FILE  DIP£CT_IO 

CE3109A  CREATE  IN  FILE  TEXT  10 


CE2203A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  an 
external  sequential  file  is  exceeded;  this  implementation  cannot 
restrict  file  capacity. 

CE2403A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  an 
external  direct  file  is  exceeded;  this  inplementation  cannot  restrict 
file  capacity. 

CE3202A  expects  that  function  NAME  can  be  applied  to  the  standard 
input  and  output  files;  in  this  isplementatlon  these  files  have  no 
names,  and  USE_ERROR  is  raised.  (See  section  2.3.) 

CE3304A  checks  that  SET_LINE_LENGTH  and  SET_PAGE_LENGTH  raise 
USE_ERROR  if  they  specify  an  inappropriate  value  for  the  external 
file;  there  are  no  inappropriate  values  for  this  Inplementation. 

CE3413B  checks  that  PAGE  raises  LAYOUT_ERROR  when  the  value  of  the 
page  number  exceeds  COUNT 'LAST;  for  this  ixiplementation,  the  value  of 
COUNT 'LAST  Is  greater  than  150000,  making  the  checking  of  this 
objective  inpractical. 
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CE2401H,  E2401D  and  EE2401G  use  instantiations  of  DZRECT_IO  with 
unconstrained  array  and  record  types;  this  ioplementation  raises 
USE_ERROR  on  the  attenpt  to  create  a  file  of  such  types. 


2.3  TEST  MODIFICATIONS 


Modifications  (see  section  1.3)  were  required  for  26  tests. 

The  following  tests  were  split  into  two  or  more  tests  because  this 
inplementation  did  not  report  the  violations  of  the  Ada  Standard  in  the  way 
expected  by  the  original  tests: 

B23004A  B24007A  B24009A  B28003A  B32202A  B32202B  B32202C  B36307A 
B37004A  B61012A  B62001B  B74304B  B74304C  B74401F  B74401R  B91004A 
B95032A  B95069A  B9S069B  BAllOlB  BC2001D  BC3009C 


BA2001E  was  graded  passed  by  Evaluation  Modification  as  directed  by  the  AVO. 
The  test  expects  that  duplicate  names  of  subunits  with  a  common  ancestor  will 
be  detected  as  con^ilation  errors;  this  isplementation  detects  the  errors  at 
link  time,  and  the  AVO  ruled  that  this  behavior  is  acceptable. 

EA3004D  was  graded  passed  by  Evaluation  and  Processing  Modification  as 
directed  by  the  AVO.  The  test  requires  that  either  pragma  INLINE  is  obeyed 
for  the  invocation  of  a  function  in  each  of  three  contexts  and  that  thus 
three  library  units  are  made  obsolete  by  the  re-conpilation  of  the  inlined 
function's  body,  or  else  the  pragma  is  ignored  completely.  This 
implementation  obeys  the  pragma  except  when  the  invocation  is  within  a 
package  specification.  When  the  test's  files  are  processed  in  the  given 
order,  only  two  units  are  made  obsolete;  thus,  the  expected  error  at  line  27 
of  file  EA3004D6M  is  not  valid  and  is  not  flagged.  To  confirm  that  indeed  the 
pragma  is  not  obeyed  in  this  one  case,  the  test  was  also  processed  with  the 
files  re-ordered  so  that  the  re-compilation  follows  only  the  package 
declaration  (and  thus  the  other  library  units  will  not  be  made  obsolete,  as 
they  are  conpiled  later) ;  a  "NOT  APPLICIABLE”  result  was  produced,  as 
expected.  The  revised  order  of  files  was  0-1-4-5-2-3-6. 

CD2A53A  wa's  graded  inapplicable  by  Evaluation  Modification  as  directed  by  the 
AVO.  The  test  contains  a  specification  of  power-of-10  value  as  small  for  a 
fixed-point  type.  The  AVO  ruled  that,  under  ACVC  1.11,  support  of  decimal 
'SMALLs  may  be  omitted. 


CE3202A  was  graded  Inapplicable  by  Evaluation  Modification  as  directed  by  the 
AVO.  This  test  applies  function  NAME  to  the  standard  input  file,  which  in 
this  implementation  has  no  name;  USE_ERROR  is  raised  but  not  handled,  so  the 
test  is  aborted.  The  AVO  ruled  that  this  behavior  is  acceptable  pending  any 
resolution  of  the  issue  by  the  ARG. 
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CHAPTER  3 


PROCESSING  INFORMATION 


3 . 1  TESTING  ENVIRONMENT 

The  Ada  implementation  tested  in  this  validation  effort  is  described 
adequately  by  the  information  given  in  the  initial  pages  of  this  report. 

For  a  point  of  contact  for  technical  information  about  this  Ada 
implementation  system,  see: 

Jean  Claude  H^liard 
Alsys  SA 

29,  Avenue  Lucien-Rene  Duchesne 
78170  La  Celle  Saint-Cloud 
France 


For  a  point  of  contact  for  sales  information  about  this  Ada  implementation 
system,  see: 


Bob  Lamkin 
Alsys  Inc 

67  South  Bedford  Street 
Burlington 
MA  01803-5152 


Nicolas  Hadjidakis 
Alsys  SA 

29,  Avenue  Lucien-Rene  Duchesne 
78170  La  Celle  Saint-Cloud 
France 


U.S.A. 


John  Stewart 
Alsys  Ltd 
Partridge  House 
Newtown  Road 
Henley-on-Thames 
Oxon,RG9  lEN 
U.K.  -  - 

Jun  Shimura 

Alsys-KKE  Co.,  Ltd 

Techno-Wave  16F 

1-1-25  Shin-Urashima-cho 

kanagawa-ku 

Yokohama  #221 

Japan 


Kurt  Wey 
Alsys  Gmbh 
Am  Rtippurer  Schoss  7 
D-7500  Karlsruhe  51 
Germany 


Orjan  Leringe 
Alys  AB 

Patron  Pehr  Vag  10 

Box  1085 

141  22  Huddinge 

Stockholm 

Sweden 


Testing  of  this  Ada  in^lementation  was  conducted  at  the  customer's  site  by 
a  validation  team  from  the  AVF. 
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3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Iiif)leinentatlon  passes  a  given  ACVC  version  if  it  processes  each  test 
of  the  customized  test  suite  in  accordance  with  the  Ada  Programming 
Language  Standard,  whether  the  test  is  applicable  or  inapplicable; 
otherwise,  the  Ada  Implementation  fails  the  ACVC  [Pro90] . 

For  all  processed  tests  (inapplicable  and  applicable),  a  result  was 
obtained  that  conforms  to  the  Ada  Programming  Language  Standard. 

The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various 
categories.  All  tests  were  processed,  except  those  that  were  withdrawn 
because  of  test  errors  (item  b;  see  section  2.1),  those  that  require  a 
floating-point  precision  that  exceeds  the  ixplementation's  maximum 
precision  (item  e;  see  section  2.2),  and  those  that  depend  on  the  support 
of  a  file  system  —  if  none  is  supported  (item  d) .  All  tests  passed,  .  . 
except  those  that  are  listed  in  sections  2.1  and  2.2  (counted  in  items  b 
and  f,  below) . 


a)  Total  Number  of  Applicable  Tests  3794 

b)  Total  Number  of  Withdrawn  Tests  95 

c)  Processed  Inapplicable  Tests  80 

d)  Non-Processed  I/O  Tests  0 

e)  Non-Processed  Floating-Point 

Precision  Tests  201 


f)  Total  Number  of  Inapplicable  Tests  281  (c+d-fe) 

g)  Total  Number  of  Tests  for  ACVC  1.11  4170  (a+b+f) 


3.3  TEST  EXECUTION 

A  Data  Cartridge  Tape  containing  the  customized  test  suite  (see  section  1.3) 
was  taken  on-site  by  the  validation  team  for  processing.  The  contents  of 
the  Data  Cartridge  Tape  were  loaded  directly  onto  the  host  computer. 

After  the'  test  files  were  loaded  onto  the  host  computer,  the  full  set  of 
tests  was  processed  by  the  Ada  inf>lementation. 
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Testing  was  performed  using  command  scripts  provided  by  the  customer  and 
reviewed  by  the  validation  team.  See  Appendix  B  for  a  complete  listing  of 
the  processing  options  for  this  in^lementation.  It  also  indicates  the 
default  options.  The  options  invoked  explicitly  for  validation  testing 
during  this  test  were: 

For  all  tests,  the  conpilatlon  options  were: 

ERRORS**999:  allow  999  errors  before  terminating  compilation. 
CALLS~INLINED :  allow  inline  Insertion  of  code  for  subprograms 
and  take  pragma  INLINE  into  account. 

REDUCTION-PARTIAL:  perform  some  high  level  optimizations  on 
checks  and  loops . 

NOWARNING:  Do  not  generate  warning  messages 
NODETAIL:  Do  not  include  extra  detail  in  error  messages 
FILEWIDTH-120 :  Listing  file  has  120  characters  per  line 
NOFILELENGTH:  Unpaginated  listing  file  -  - 


For  tests  rejected  at  compile  time,  the  two  compilation  options  were  used 
additionally: 

TEXT:  Compilation  listing  including  full  source  text  (with 
embedded  error  messages) 

SHOW-NONE:  No  banner  header  on  listing  pages,  no  error 
summary  at  end  of  listing. 

For  tests  corrpiled  without  errors,  the  con^Jilation  option  was  used 
additionally: 

NOTEXT:  Compilation  listing  including  only  source  text  for 
lines  containg  errors 
(i.e.  empty  listing  if  no  errors) 

For  all  tests,  the  binder  options  were: 

NOWARNING:  Do  not  generate  warning  messages 
FILEWIDTH-80:  Listing  file  has  80  characters  per  line 
NOFILELENGTH:  Unpaginated  listing  file 
TASK-12:  The  default  programm  stack  size  for  all  tasks 
is  12k. bytes. 


The  binder  use  the  following  options  of  the  UNIX  linker  Id  : 

-dc  -dp  -e  start  -X  -o  SWD/Sl  /user/lib/crtO .o  $WD/$l.o 
SALSYCOMP  DlR/libada.a  -Ic 


Test  output,  con^iler  linker  listings,  and  job  logs  were  captured  on 
Data  Cartridge  Tape  and  archived  at  the  AVF.  The  listings  examined  on-site 
by  the  validation  team  were  also  archived. 
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MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  used  for  customizing  the  ACVC. 
The  meaning  and  purpose  of  these  parameters  are  ej^lained  in  [UG89] .  The 
parameter  values  are  presented  in  two  tables.  The  first  table  lists  the 
values  that  are  defined  in  terms  of  the  maximum  Input-line  length,  which  is 
the  value  for  $MAX_IN_LEN--also  listed  here.  These  values  are  expressed 
here  as  Ada  string  aggregates,  where  "V"  represents  the  maximum  input-line 
length . 


Macro  Parameter 


Macro  Value 


$MAX_1N_LEN 

255  —  Value 

of  V 

$BIG_1D1 

(1..V-1  ->  'A', 

V  ->  '1') 

$BIG_ID2 

(1..V-1  ->  'A', 

< 

1 

V 

$BIG_ID3 

(1..V/2  ->  'A') 
<1, .V-l-V/2 

4  '3'  4 
->  'A') 

$BIG_ID4 

<l..V/2  ->  'A') 
(1. .V-l-V/2 

4  '4'  4 
->  'A') 

$BIG_INT_LIT 

(1..V-3  ->  '0') 

4  "298" 

$BIG_REAL_LIT 

(1..V-5  ->  '0') 

4  -690.0" 

SBIG_STRING1 

6  (1..V/2  -3 

►  'A')  4 

$BIG_STRING2 

«  (1.. V-l-V/2  ->  'A')  4 

$BLANKS 

(1..V-20  ->  '  ») 

$MAX_LEN_INT_BASED_LITERAL 

"2;"  C  (1..V-5  ->  »0')  &  "11:" 

$MAX_LEN_REAL_BASED_LITERAL 

"16:"  «  (1..V-7  ->  '0')  6  "F.E:" 

$MAX_STRING_LITERAL  «  (1..V-2  ->  'A')  t 


A-1 


MACRO  PARAMETERS 


The  following  table  lists  all  of  the  other  macro  parameters  and  their 
respective  values. 


Macro  Parameter  Macro  Value 


SACC_SIZE 

SALIGNMENT 

$COUNT_LAST 

$DEFAULT_MEM_S  1 2E 

$DEFAULT_STOR_UNIT 

$DEFAULT_SYS_NAME 

$DELTA_DOC 

$ENTRy_ADDRESS 

$ENTRY_ADDRESS 1 

$ENTRY_ADDRESS2 

$FIELD_LAST 

$FILE_TERMINATOR 

$FIXED_NAME 

$FLOAT_NAME 

SFORM_STRING 

$FO^_STRING2 

SGREATER  THAN  DURATION 


32 

2 

2147463647 

2**32 

8 

SPARC 

2#1.0#E-31 

INTERRUPT_ADDRESS 

INTERRUPT_ADDRESS 1 

INTERRUPT_ADDRESS2 

255 

CHARACTER' VAL ( 32 ) 

NO_SUCH_TYPE 

NO_SUCH_TYPE 

m  wt 

"CANNOT_RES  TRICT_F I LE_C AP AC I T Y" 

100  000.0 


SGREATER  THAN  DURATION  BASE  lAST  100  000  000.0 


SGREATER  THAN  FLOAT  BASE  LAST  2.0E128 


SGREATER  THAN  FLOAT  SAFE  LARGE  2#1 . 11111111111111111111111#E127 


$GREATER_THAN_SHORT_FLOAT_SAFE_ 

_LARGE 

$HIGH_PRIORITY 

10 

$  I  LLEGA1._EXTERNAL_F  I  LE_NAME  1 

$ I LLEGAL_EXTERNAL_F ILE_NAME2 

/-/*/f2 

$ INAPPROPRIATE_LINE_LENGTH 

-1 

$ INAPPROPRI ATE_PAGE_LENGTH 

-1 

$ INCLUDE_PRAGMA1 

PRAGMA  INCLUDE 

(-A28006D1.TST") 

$  INCI.ODE_PRAGMA2 

PRAOIA  INCLUDE 

("B28006D1.TST") 

$INTEGER_FIRST 

-2147483648 

$INTEGER_LAST 

2147483647 

$ INTEGER_LAST_PLUS_1 

2_147_483_648 

$ INTERFACE_LANGUAGE 

C 

$ LESS_THAN_DURAT ION 

-100_000.0 

$  LES  S_THAN_DURATION_BASE_F IRST 

-100_000_000.0 

$LINE_TERMINATOR 

ASCII. LF 

$LOW_PRIORITY 

1 

$MACH INE_CODE_STATEMENT 

NULL; 

$MACHINE_CODE_TYPE 

NO_SUCH_TYPE 

$MANTISSA_DOC 

31 

$MAX_DIGITS 

15 

' 

$MAX_INT 

2147483647 

$MAX_INT_PLUS_1 

2_147_483_648 

$MIN_INT 

-2147483648 

A- 

-3 

$NAME 

SHORT_SHORT_INTEGER 

$NAME_LIST  180X86, 

I80386,MC680X0, S370, TRANSPUTER, VAX, SPARC 

$NAME_SPECIFICATI0N1 

/tRp/X2120A 

$NAME_SPECIFICATION2 

/tii9/X2120B 

$NAME_SPEC IF ICAT ION3 

/tinp/X3119A 

$NEG_BASED_INT 

16#FFFFFFFE# 

$NEW_MEM_S1ZE 

2**32 

$NEW_STOR_UNIT 

8  -  ■■ 

$NEW_SYS_NAME 

SPARC 

$PAGE_TERMINATOR 

ASCII. FF 

$RECORD_DEFINITION 

new  INTEGER; 

$RECORD_NAME 

NO_SUCH_MACHINE_CODE_TYPE 

$TASK_SIZE 

32 

$TASK_STORAGE_S I ZE 

10240 

$TICK 

0.02 

$VARIABLE_ADDRESS 

OBJECT_ADDRESS 

$VARIABLE_AODRESS 1 

0BJECT_ADDRESS1 

$VARIABLE_ADDRESS2 

OBJECT_ADDRESS2 

$XOUR_P*^®^ 

INTERFACE__NAME 
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OPTIONS 

The  options  of  this  Ada  in^lementatlon,  as  described  in  this 
Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  compiler  documentation  and 
not  to  this  report. 


COMPILATION  SYSTEM  OPTIONS 

This  is  the  list  of  options.  The  default  values  are  indicated. 


COMPILE  (SOURCE 

-> 

0 

LIBRARY 

-> 

0 

OPTIONS 

■>> 

(ANNOTATE 

-> 

no  value 

ERRORS 

-> 

50, 

LEVEL 

-> 

UPDATE, 

CHECKS 

-> 

ALL, 

GENERICS 

-> 

INLINE, 

MEMORY 

-> 

500), 

DISPLAY 

-> 

(OUTPUT 

-> 

SCREEN, 

WARNING 

-> 

YES, 

TEXT 

-> 

NO, 

SHOW 

-> 

ALL, 

DETAIL 

-> 

YES, 

ASSEMBLY 

-> 

NONE) , 

IMPROVE 

-> 

(CALLS 

-> 

NORMAL, 

REDUCTION 

-> 

NONE, 

EXPRESSIONS 

-> 

NONE, 

OBJECT 

-> 

NONE) , 

KEEP 

-> 

(TREE 

-> 

NO, 

DEBUG 

-> 

NO, 

COPY 

-> 

NO, 

DIAGNOSTICS 

-> 

NO), 

ALLOCATION 

m> 

(CONSTANT 

-> 

0, 

GLOBAL 

-> 

0)); 

B-1 


BINDER  OPTIONS 


This  is  the  list  of  options.  The  default  values  are  indicated. 

BIND  (PROGRAM  ->>  , 

LIBRARY  ->  , 


OPTIONS 

-> 

(LEVEL 

-> 

LINK, 

OBJECT 

-> 

AUTOMATIC, 

UNCALLED 

-> 

REMOVE, 

SLICE 

»> 

NO, 

BLOCKING 

-> 

A0T(»1ATIC) 

STACK 

-> 

(MAIN 

-> 

16, 

TASK 

-> 

20, 

HISTORY 

->  MAIN), 

INTERFACE 

-> 

(DIRECTIVES 

-> 

no_value. 

MODULES 

-> 

no_value. 

SEARCH 

-> 

no_value) , 

DISPLAY 

-> 

(OUTPUT 

-> 

SCREEN, 

DATA 

-> 

NONE, 

WARNING 

-> 

YES), 

KEEP 

-> 

(DEBUG 

■> 

NO) )  ; 

LINKER  OPTIONS 

The  binder  use  the  UNIX  linker  Id. 
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APPENDIX  F  OF  THE  Ada  STANDARD 


The  only  allowed  inpleroentation  dependencies  correspond  to 
implementation-dependent  pragmas,  to  certain  machine -dependent  conventions 
as  mentioned  in  Chapter  13  o£  the  Ada  Standard,  and  to  certain  allowed 
restrictions  on  representation  clauses.  The  implementation-dependent 
characteristics  of  this  Ada  in^lementation,  as  described  in  this  Appendix, 
are  provided  by  the  customer.  Unless  specifically  noted  otherwise, 
references  in  this  ^pendix  are  to  compiler  documentation  and  not  to  this 
report . 

Implementation-specific  portions  of  the  package  STANDARD  are  presented 
on  page  16  of  tl  s  Appendix. 
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CHAPTER  1 


IMPLEMENTATION-DEPENDENT  PRAGMAS 


1.1  The  Pragma  INTERFACE 

Programs  written  in  Ada  can  interface  with  external  subprograms  written  in  another  . 
language,  by  use  of  the  pragma  INTERFACE  The  format  of  the  pragma  is: 

pragma  INTERFACE  (language  jiame,Ada_subprogram_namey, 

Thelanguagejiame  may  be  Assembler,  C  or  Fortran  used  (seeApplication 
Developer’s  Guide). 

The  Ada  subprogram  jiame  is  the  name  by  which  the  subprogram  is  known  in  Ada. 

Interfacing  the  Ada  language  with  other  languages  is  detailed  in  xhe  Application 
Developer’s  Guide. 


1.2  The  Pragma  INTERFACE_NAME 

To  name  the  external  subprogram  to  which  an  Ada  subprogram  is  interfaced,  as  deHned 
in  the  other  language,  may  require  the  use  of  non-Ada  naming  conventions,  such  as 
special  characters,  or  case  sensitivity.  For  this  purpose  the  implementation-dependent 
pragma  INTERFACE.NAME  may  be  used  in  conjunaion  with  the  pragma  INTERFACE 

pragma  INTERFACE_NAME  (Ada_subprogram_name,  name_sbing); 

llie  name  string  is  a  string,  which  denotes  the  name  of  the  external  subprogram  as 
defined  in  the  other  language.  The Adasubprogramjuime  is  the  name  by  which  the 
subprogram  is  known  in  Ada. 


Implementation-Dependent  Pragmas 
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The  pragma  INTERFACE_NAME  may  be  used  anywhere  in  an  Ada  program  where 
INTERFACE  is  allowed  (see  [13.9]*).  It  must  occur  after  the  corresponding  pragma 
INTERFACE  and  within  the  same  declarative  part  or  package  specification. 


13  The  Pragma  INLINE 

Pragma  INLINE  is  fully  supported;  however,  it  is  not  possible  to  inline  a  subprogram  in  a 
declarative  part. 

Note  that  inlining  facilities  are  also  provided  by  use  of  the  command  COMPILE  with  the 
option  IMPROVE  (see  the  User's  Guide). 


1.4  The  Pragma  EXPORT 

The  pragma  EXPORT  takes  a  language  name  and  an  Ada  identifier  as  arguments.  This 
pragma  allows  an  object  defined  in  Ada  to  be  visible  to  external  programs  written  in  the 
specified  language. 

pragma  EXPORT  (language  jiame,  Ada  Jdentifier) 

Example: 

package  MY_PACKAGE  is 

THIS_OBJECT :  INTEGER; 
pragma  EXPORT  (C,  THIS_OBJECr); 

end  MY_PACKAGE; 


*  Throughout  this  manual,  ciutions  in  square  brackets  refer  to  the  R^erence  Manual 

for  the  Ada  Programming  Language,  ANSI/MIL-STD  1815A,  February  1983,  includ¬ 
ing  Appendix  F  for  this  implementation. 
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Limitations  on  the  nse  of  pragma  EXPORT 

•  This  pragma  must  occur  in  a  declarative  part  and  applies  only  to  objects  declared  in 
this  same  declarative  part,  that  is,  generic  instantiate  objects  or  renamed  objects 
are  excluded. 

■  The  pragma  is  only  to  be  used  for  objects  with  direa  allocation  mode,  vriiich  are 
decided  in  a  library  package.  The  ALSYS  implemenution  gives  indirect  allocation 
mode  to  dynamic  objects  (see  Section  2.1  of  Application  Developer’s  Guide). 


1.5  The  Pragma  EXTERNAL^NAME 

To  name  an  exported  Ada  objea  as  it  is  identified  in  the  other  language  may  require  the 
use  of  non-Ada  naming  conventions,  such  as  special  charaaeis,  or  case  sensitivity.  For 
this  purpose  the  implementation-dependent  pragma  EXTERNAL_NAM£  may  be  used  in 
conjunaion  with  the  pragma  EXPORT: 

pragma  EXTERNAL^NAME  (Adajdentifier,  namejtring)-. 

The  namejtring  is  a  string  which  denotes  the  name  of  the  identifier  defined  in  the  other 
language.  The  Adajdentifier  denotes  the  exported  Ada  object 

The  pragma  EXTERNAL.NAME  may  be  used  anywhere  in  an  Ada  program  where 
pragma  EXPORT  is  allowed.  It  must  occur  after  the  corresponding  pragma  EXPORT  and 
within  the  same  library  package. 

Example: 

package  MY_PACKAGE  is 

THIS  OBJECT :  INTEGER; 
pragma  EXPORT  (C,  THIS_OBJECT); 

{Hiigma  EXTERNAL_NAME  (THIS_OBJECT,  "ThisObject*); 


end  MY_PACKAGE; 
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1.6  The  Pragma  INDENT 

This  pragma  is  only  used  by  AdaReformat  This  tool  offers  the  functionality  of  a  pretty- 
printer  in  an  Ada  environment 

The  pragma  is  placed  in  the  source  file  and  interpreted  by  AdaReformat 

pragma  INDENT(OFF)  causes  AdaReformat  not  to  modify  the  source  lines  after 
this  pragma. 

pragma  INDENT(ON)  causes  AdaReformat  to  resume  its  action  after  this  pragma. 


1.7  The  Pragma  IMPROVE 

This  pragma  is  used  to  suppress  implicit  components  from  a  record  type. 

pragma  IMPROVE  (TIME  |  SPACE,  (ON  *>]  simple_name); 
See  Section  4.8,  Record  Types,  for  the  complete  description. 


1.8  The  other  Pragmas 

Pragma  PACK  is  discussed  in  detail  in  the  section  on  represenution  clauses  and  records 
(Chapter  4). 

Pragma  PRIORITY  is  accepted  with  the  range  of  priorities  running  from  1  to  10  (see  the 
definition  of  the  predefined  package  SYSTEM  in  Seaion  3).  Undefined  priority  (no 
pragma  PRIORITY)  is  treated  as  though  it  were  less  than  every  defined  priority  value. 

In  addition  to  pragma  SUPPRESS,  it  is  possible  to  suppress  all  checks  in  a  given 
compilation  by  the  use  of  the  Compiler  option  CHECKS.  (See  Chapter  4  of  the  User’s 
Guide.) 
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1.9  Pragmas  with  no  Effect 

The  foUowing  pragmas  have  no  effect: 

CONTROLLED 

MEMORY_SIZE 

STORAGE_UNIT 

SYSTEM_NAME 

OPTIMIZE 

For  optimization,  certain  facilities  are  provided  through  use  of  the  command  COMPILE 
with  the  option  IMPROVE  (see  the  User’s  Guide). 
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CHAPTER  2 


IMPLEMENTATION-DEPENDENT  ATTRIBUTES 


Throughout  this  chapter  and  the  remaining  chapters  of  this  document  three  special  types 
of  integer  are  used  in  the  text.  They  are  used  where  the  number  of  bits  used  to  store  the 
integer  is  important 

The  three  types  used  are  defined  as:  ~  ' 

INTEGER_8;  an  integer  stored  in  8  bits, 

INTEGER_16;  an  integer  stored  in  16  bits, 

INTEGER_32;  an  integer  stored  in  32  bits. 

and  can  be  respeaively  declared,  with  representation  clauses,  thus: 

type  INTEGER  8  Is  new  INTEGER  range  -2**7 ..  2**7  -1; 
for  INTEGErJ’SIZE  use  8; 

type  INTEGER  16  to  new  INTEGER  range  •2*M5 ..  2**15  -1; 
for  INTEGER  J6’SIZE  use  16; 

type  INTEGER  32  to  new  INTEGER  range  -2*‘31 ..  2**31  -1; 
for  INTEGERjrSIZE  use  32; 

The  user  gains  complete  control  over  the  data  storage  by  using  these  fonns  of 
declaration,  as  opposed  to  those  defined  in  package  STANDARD  over  which  the  user 
has  no  control.  (Refer  to  Chapter  3  of  this  document) 

Note:  The  user  may  omit  the  representation  clauses  in  the  above  examples  as  the  current 
implemetation  of  the  compiler  uses  these  sizes  by  default. 
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2.1  Attributes  used  in  Record  Representation  Clauses 

In  addition  to  the  Representation  Attributes  of  [13.7.2]  and  [13.7.3],  the  following  five 
attributes  are  used  to  form  names  of  indirea  and  implicit  components  for  use  in  record 
representation  clauses,  as  described  in  Seaion  4.8. 

’OFFSET 
’RECORD  SIZE 
’VARIANT  INDEX 
’ARRAY  DESCRIPTOR 
’RECORD^DESCRIPTOR 

2.2  Limitations  on  the  use  of  the  Attribute  ADDRESS 

The  attribute  ADDRESS  is  implemented  for  all  prefixes  that  have  meaningful  addresses. 

Note:  The  value  returned  by  the  attribute  ADDRESS  changes  after  the  elaboration  of  the 
subprogram  body  (when  ’ADDRESS  is  applied  to  a  subprogram). 

The  following  entities  do  not  have  meaningful  addresses  and  will  therefore  cause  a 
compilation  error  if  used  as  prefix  to  ADDRESS: 

■  A  constant  that  is  implemented  as  an  immediate  value,  i.e.,  does  not  have  any  space 
allocated  for  it 

■  A  package  specification  that  is  not  a  library  unit 

■  A  package  body  that  is  not  a  library  unit  or  subunit 

■  A  function  that  renames  an  enumeration  literal. 


2J  The  Attribute  IMPORT 

This  attribute  is  a  fiinaion  which  takes  two  literal  strings  as  arguments;  the  first  one 
denotes  a  language  name  and  the  second  one  denotes  an  external  symbol  name.  It  yields 
the  address  of  this  external  symbol.  The  prefix  of  this  atuibute  must  be 
SYSTEMADDRESS.  The  value  of  this  attribute  is  of  the  type  SYSTEMADDRESS.  The 
syntax  is: 

SYSTEM  ADDRESS’IMPORT  {’Language jumie’,  'external jynAoljtame’) 
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Following  are  two  examples  which  illustrate  the  use  of  this  attribute. 

Example  1: 

SYSTEMj\DDRESS*IMPORT  is  used  in  an  address  clause  in  order  to  access  a  global 
object  defined  in  a  C  library: 

For  the  language  C: 

int  ermo; 


For  the  language  Ada: 

package  MY_PACK  is 

ERROR  NO :  INTEGER  32; 

for  ERr6r_NO  use  at  SYSTEM-ADDRESS’IMPORT  ("C,  "ermo"); 
end  MY_PACK; 

Note  that  implicit  initializations  are  performed  on  the  declaration  of  objects;  objects  of 
type  access  are  implicitly  initialized  to  null. 

Example  2: 

The  second  example  shows  another  use  of ’IMPORT  which  avoids  implicit 
initializations. 

SYSTEM-ADDRESS’IMPORT  is  used  in  a  renaming  declaration  to  give  a  new  name  to  an 
external  object: 

For  the  language  C: 

strum  record_c  { 
short  il; 
short  12; 

}req 


Implementation-Dependent  Attributes 


9 


For  the  language  Ada: 


typeRECORD_Cl8 

record 

II:  INTEGER  16; 

12 :  INTEGER_16; 
end  record; 

type  ACCESS  RECORD  is  access  RECORD  C; 
fiinction  CONVERT  TO  ACCESS  RECORD  is  new 

UNCIffiCKED_CONVERSION 
(SYSTEM. ADDRESS,  ACCESS  RECORD); 

X:  RECORD  C  renames  CONVERT  TO  ACCESS  RECO^ 

(SYSTEM. ADDRESyiMPORTfC-,  ’rec")  ).ail; 

In  this  example,  no  implicit  initialization  is  done  on  the  renamed  object  X. 

Note  that  the  object  is  actually  defined  in  the  external  world  and  is  only  referenced  in  the 
Ada  world. 


10 


Appendix  F  Version  5 


CHAPTERS 


THE  PACKAGES  SYSTEM  AND  STANDARD 


This  section  contains  information  on  two  predefined  library  packages: 

■  a  complete  listing  of  the  visible  part  of  the  specification  of  the  package  SYSTEM 

■  a  list  of  the  implementation-dependent  declarations  in  the  package  STANDARD, 
package  SYSTEM  la 

-  Standard  Ada  definitions 

type  NAME  Is  (180X86,  I80386,  MC680X0,  S370,TRANSPLniER,  VAX,  SPARC) ; 


SYSTEM  NAME 

:  constant  NAME  :=  SPARC; 

STORAGE  UNIT 

;  constant  :=  8 ; 

MEMORY"siZf 

:  constant  :=  2**32; 

MIN  INT 

:  constant  := -(2**31) ; 

MAX  INT 

:  constant  2**31-1 ; 

MAX  DIGITS 

:  constant  IS; 

MAX  MANTISSA 

:  constant  31 ; 

fine“delta 

:  constant  :=  2#1.0#e-31 ; 

TICK 

;  constant  :=  0.02 ; 

type  ADDRESS  Is  private; 

NULL_ADDRESS :  constant  ADDRESS; 

subtype  PRIORITY  is  INTEGER  range  1..10; 
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-  Address  operations 

ftinction  VALUE  (LEFT :  in  STRING)  return  ADDRESS; 


-  Converts  a  string  into  an  address. 

-  The  string  can  represent  either  an  unsigned  address  ie. 

-  ■'16#XXXXXXXX#*  where  XXXXXXXX  is  in  the  range 
--  O..FFFFFFFF,  or  a  signed  address  ic. 

--  '-16#XXXXXXXX#'  where  XXXXXXXX  is  in  the  range 
--  0..7FFFFFFF. 

--  A  CONSTRAINT_ERROR  is  raised  if  the  string  does  not  conform  to 

-  this  syntax 


subtype  ADDRESS_STRING  is  STRING(1..8); 

function  IMAGE(  LEFT :  in  ADDRESS  )  return  ADDRESS_STRING; 


••  Converts  an  address  to  a  string.  The  syntax  of  the  returned  string  is 
--  described  in  the  VALUE  function  above.  Refer  to  the  unsigned 
••  representation. 


type  OFFSET  is  range  -2**31 ..  2**3l  -1; 

••  This  type  is  used  to  measure  a  number  of  storage  units  (bytes). 

••  The  type  is  an  Ada  integer  type. 

function  SAME_SEGMENT  (LEFT,  RIGHT :  in  ADDRESS)  return  BOOLEAN; 

- On  a  segmented  architecture 

the  function  returns  TRUE  if  the  two 

••  addresses  have  the  same  segment  value.  On  a  non-segmented 

--  architecture  it  always  returns  TRUE. 
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ADpRESS_ERROR :  exception; 


--  This  exception  is  raised  by  '<•,  *<  •> ="  and if  the  two 

-  addresses  do  not  have  the  same  segment  value.  This  exception  is 

-  never  raised  on  a  non-segmented  machine. 

-  The  exception  CONSTTlAINT_ERROR  can  be  raised  by  *+"  and  *-*. 


fiinction  '+*  (LEFT :  in  OFFSET;  RIGHT ;  in  ADDRESS)  return  ADDRESS; 
function  ■+■•  (LEFT ;  in  ADDRESS;  RIGHT :  in  OFFSET)  return  ^DRESS; 
fiinction (LEFT :  in  ADDRESS;  RIGHT :  in  OFFSET)  return  ADDRESS; 


"  These  routines  provide  support  to  perform  address  computations.  The 
--  meaning  of  the  '+*  and  operators  is  architecture  dependent.  For 
~  example  on  a  segmented  machine  the  OFFSET  parameter  is  added  to, 
-  or  subtracted  from  the  offset  part  of  the  address,  the  segment 
••  remaining  unaltered. 


function  (LEFT ;  in  ADDRESS;  RIGHT :  in  ADDRESS)  return  OFFSET; 


"  Returns  the  distance  between  the  ^en  addresses.  The  result  is 
••  signed.  The  exception  ADDRESS^ERROR  is  raised  on  a  segmented 
••  architeaure  if  the  two  addresses  do  not  have  the  same  segment  value. 


function  *<"  (LEFT,  RIGHT :  in  ADDRESS)  return  BOOLEAN; 
fiinction  *<  ="  (LEFT,  RIGHT :  in  ADDRESS)  return  BOOLEAN; 
function  ’>"  (LEFT,  RIGHT :  in  ADDRESS)  return  BOOLEAN; 
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function  *>="  (LEFT,  RIGHT :  in  ADDRESS)  return  BOOLEAN; 


"  Perform  a  comparison  on  addresses,  or  on  the  offset  part  of  addresses 

-  for  a  segmented  machine.  The  comparison  is  unsign^  on  all 

-  machines  except  the  Transputer. 


Auction  'mod*  (LEFT :  in  ADDRESS;  RIGHT :  in  POSITIVE) 
return  NATURAL; 


-  Returns  the  offset  of  LEFT  relative  to  the  memoiy  block  immediately 
--  below  it  starting  at  a  multiple  of  RIGHT  storage  units.  On  a 
~  segmented  machine,  the  segment  part  is  ignored. 


type  ROUND_DIRECTION  U  (DOWN,  UP); 

function  ROUND  (  VALUE :  in  ADDRESS; 

DIRECTION :  in  ROUND  DIRECTION; 
MODULUS :  in  POSITIVE )  return  ADDRESS; 

--  Returns  the  given  address  rounded  to  a  specific  value. 


generic 

type  TARGET  is  private; 

function  FETCH_FROM_ADDRESS  (A :  in  ADDRESS)  return  TARGET; 
generic 

type  TARGET  is  private; 

procedure  ASSIGN_TO_ADDRESS  (A :  in  ADDRESS;  T :  in  TARGET); 


~  These  routines  are  provided  to  perform  READ/WRITE  operations  in 
-  -memory.  These  routines  may  give  uncqtected  results  if  used  with 
-  unconstrained  types. 
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type  OBJECT_LENGTH  is  range  0 ..  2**31  - 1; 

-  This  type  is  used  to  designate  the  size  of  an  object  in  storage  units. 

procedure  MOVE  (  TO :  In  ADDRESS; 

FROM:  In  ADDRESS; 

LENGTH :  in  OBJECT  LENGTH ); 


"  Copies  LENGTH  storage  units  starting  at  the  address  FROM  to  the 
--  address  TO.  The  source  and  destination  may  overlap. 

~  Use  of  this  procedure  with  optimizers  may  lead  to  unexpected 
-  results. 


private 

"  private  part  of  the  system 
end  SYSTEM; 
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The  packafe  STANDARD 

The  following  are  the  ImplemenuUon-dependent  declarations  in  the  package 
STANDARD: 

type  SHORT_SHORT  INTEGER  te  range  -2**7  >  2**7  -1; 
type  SHORT  INTEGER  la  range  -2**15 ..  2«*15  -1; 

type  INTEGER  la  range  -2**31  „  2**31  -1; 

type  SHORT  FLOATla  digits  6range 

-2#Liiiliii  nil  nil  nil  nn#E+i27.. 

2#i.i  irnirnn jnrniOni#E + 127 

type  FLOATla  digits  orange 

-2#  1.111  nil  nil  nil  1111  nn#E+i27.. 

2#i.ni2nn“nn jnOnOln^^'E + 127 

Qrpe  LONG  FLOATla  digits  Ifrange 

.2#i.nn  nil  iin  1111 1111 1111 1111 1111  1111 1111 
nil  nirnn#E+Io23 .7 

2#Lnn  hn  1111 1111 1111 1111 1111 1111 1111 1111 
nn_nn_nn#E +“1023“ 

type  DURATION  b  delta  2#0.000  000  000  000  01#  range 
-2.0**17 10**17-L0; 

~  Th&maximuin  precision  allowed  for  this  ranget  2.0**(14) 
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CHAPTER  4 


TYPE  REPRESENTATION  CLAUSES 

The  aim  of  this  section  is  to  explain  how  objects  are  represented  and  allocated  by  the 
Alsys  Ada  compiler  for  SPARC  machines  and  how  it  is  possible  to  control  this  using 
representation  clauses. 

The  representation  of  an  object  is  closely  connected  with  its  type.  For  this  reason  this ' 
section  addresses  successively  the  representation  of  enumeration,  integer,  floating  point, 
fixed  point,  access,  task,  array  and  record  types.  For  each  class  of  type  the  representation 
of  the  corresponding  objects  is  described. 

Except  in  the  case  of  array  and  record  types,  the  description  for  each  class  of  type  is 
independent  of  the  others.  To  understand  the  representation  of  an  array  type  it  is 
necessary  to  understand  first  the  representation  of  its  components.  The  same  rule  applies 
to  record  types. 

Apart  from  implementation  defined  pragmas,  Ada  provides  three  means  to  control  the 
size  of  objects: 

■  a  (predefined)  pragma  PACK,  when  the  object  is  an  array,  an  array  component,  a 
record  or  a  record  component 

■  a  record  representation  clause,  when  the  object  is  a  record  or  a  record  component 

■  a  size  specification,  in  any  case. 

For  each  class  of  types  the  effect  of  a  size  specification  alone  is  described.  Interference 
between  size  specifications,  packing  and  record  represenution  clauses  is  described  under 
array  and  record  types. 
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4.1  Enumeration  l^pes 

Internal  codes  of  enumeratloa  literals 

When  no  enumeration  representation  clause  applies  to  an  enumeration  type,  the 
internal  code  associated  with  an  enumeration  literal  is  the  position  number  of  the 
enumeration  literal.  Then,  for  an  enumeration  type  with  n  elements,  the  internal  codes 
are  the  integers  0, 1, 2, ,  n-1. 

An  enumeration  representation  clause  can  be  provided  to  specify  the  value  of  each 
internal  code  as  described  in  [13.3].  The  Alsys  compiler  fully  implements  enumeration 
representation  clauses.  -  ' 

As  internal  codes  must  be  machine  integers  the  internal  codes  provided  by  an 
enumeration  representation  clause  must  be  in  the  range  -23i ..  23i  -1. 

Encoding  of  enumeration  values 

An  enumeration  value  is  always  represented  by  its  internal  code  in  the  program 
generated  by  the  compiler. 

When  an  enumeration  type  is  not  a  boolean  type  or  is  a  boolean  type  with  an 
enumeration  represenution  clause,  binary  code  is  used  to  represent  internal  codes. 
Negative  codes  are  then  represented  using  two’s  complement 


Minimum  size  of  an  enumeration  subtype 

The  minimum  size  of  an  enumeration  subtype  is  the  minimum  number  of  bits  that  is 
necessary  for  representing  the  internal  codes  of  the  subtype  values  in  normal  binary 
form. 

For  a  static  subtype,  if  it  has  a  null  range  its  minimum  size  is  1.  Otherwise,  if  m  and  M  are 
the  values  of  the  internal  codes  associated  with  the  first  and  last  enumeration  values  of 
the  subtype,  then  its  minimum  size  L  is  determined  as  follows.  For  m  >  s  0,  L  is  the 
smallest  positive  integer  such  that  M  <  «  2L-1.  For  m  <  0,  L  is  the  smallest  positive 
integer  such  that  -2H  <  =  m  and  M  <  »  -1. 
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type  COLOR  U  (GREEN,  BLACK,  WHITE,  RED,  BLUE,  YELLOW); 

-  The  minimum  size  of  COLOR  is  3  bits. 

subtype  BLACK_AND_WHITE  is  COLOR  ranee  BLACK ..  WHITE; 

-  The  minimum  size  ofBLACK_AND_WHITE  is  2  bits. 

subtype  BLACK_OR_WHITE  is  BLACK_AND_WHITE  nu^  X ..  X; 

~  Assuming  that  X  is  not  static,  the  minimum  size  of  BLACK_OR_WHITE  is 
~  2  bits  (the  same  as  the  minimum  size  of  its  type  mark  BLACK_AND_WHITE). 


Size  of  an  enumeration  subtype 

When  no  size  specification  is  applied  to  an  enumeration  type  or  first  named  subtype,  the 
objects  of  that  type  or  first  named  subtype  are  represented  as  signed  or  unsigned  machine 
integers.  The  machine  provides  8, 16  and  32  bit  signed  integers,  and  8  or  16  bit  unsigned 
integers.  The  compiler  automatically  selects  the  smallest  machine  integer  which  can 
hold  each  of  the  internal  codes  of  the  enumeration  type.  The  size  of  the  enumeration 
type  and  of  any  of  its  subtypes  is  thus  8, 16  or  32  bits. 

When  a  size  specification  is  applied  to  an  enumeration  type,  this  enumeration  type  and 
each  of  its  subtypes  has  the  size  specified  by  the  length  clause.  The  same  rule  applies  to  a 
first  named  subtype.  The  size  specification  must  of  course  specify  a  value  greater  than  or 
equal  to  the  minimum  size  of  the  type  or  subtype  to  which  it  applies: 
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type  EXTENDED  is 


The  usual  American  ASCII  characters. 
NUL,  SOH,  STX,  ETX. 

EOT, 

ENQ, 

ACK, 

BEL, 

BS, 

HT, 

LF. 

VT. 

FF. 

CR, 

SO, 

SI. 

DLE, 

DCl, 

DC2. 

DCS, 

DC4, 

NAK, 

SYN, 

ETB, 

CAN, 

EM. 

SUB. 

ESC, 

FS, 

GS, 

RS, 

US. 

»  • 

•I* 

•  » 

MIS 

9 

’#*. 

T, 

’%•, 

’&*. 

Iff 

9 

*)’. 

»•* 

* 

9  9 

9  9 

9  9 
*  * 

»  * 

•  9 

r. 

*0*. 

T*. 

*2’, 

•3’. 

’4*. 

’5-. 

•6’. 

'T, 

•8’. 

■9‘, 

•  9 

s.s 

9  S 

““  1 

•V 

•  I 

•A*. 

•B*. 

’C. 

’D*. 

•E’. 

•F, 

.’G’, 

’H’, 

T. 

T. 

’K'. 

•L*. 

’M’. 

’N\ 

•O’, 

•P*. 

•O'. 

•R*. 

•S’. 

'T, 

‘U*. 

•w*. 

’X*. 

•V. 

r. 

T. 

V. 

s  ^  s 

9 

9  9 

^  9 

•4S 

1 

•a’. 

V, 

•c*. 

•d-, 

’c’. 

T, 

y. 

’h’. 

*i’. 

T. 

’if. 

r. 

•m’. 

’n\ 

•o’. 

’P’. 

•q’. 

•r’. 

V. 

r. 

’u’. 

V, 

•w’. 

v, 

y, 

v. 

*{*. 

r. 

9  9 

9 

DEL, 

••  Extended  characters 


LEFT  ARROW. 

RIGFfT  ARROW, 

UPPER  ARROW. 

LOWER  ARROW, 

UPPER  LEFT  CORNER. 

upper“right  corner. 

LOWER  RIGHf  CORNER, 

lower’left  corner 


for  EXTENDED’SI21E  asc  8; 

"  The  size  of  type  EXTENDED  will  be  one  byte.  Its  objects  will  be  represented 
-  as  unsigned  8  bit  integers. 


The  Alsys  compiler  fully  implements  size  specifications.  Nevertheless,  as  enumeration 
values  are  coded  using  integers,  the  specified  length  cannot  be  greater  than  32  bits. 


Size  of  the  objects  of  an  enamcratioa  subtype 

Provided  its  size  is  not  constrained  by  a  record  component  clause  or  a  pragma  PACK,  an 
object  of  an  enumeration  subtype  has  the  same  size  as  its  subtype. 
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Alignment  of  the  objects  of  an  enumeratloo  subtype 

An  object  of  an  enumeration  subtype  is  byte  aligned  if  the  size  of  the  objea  is  less  than 
or  equal  to  8  bits,  it  is  otherwise  even  byte  aligned  if  its  size  is  less  than  or  equal  to  16. 
Otherwise  it  is  word  (4  byte)  aligned. 


4.2  Integer  lypes 

Predefined  integer  types 

There  are  three  predefined  integer  types  in  the  Alsys  implementation  for  SPARC  -  -■ 
machines: 

type  SHORT  SHORT  INT1EGER  is  range  -2**7 ..  2**7  -1; 
type  SHORT  INTEGER  is  range  -2**15 ..  2*‘15  -1; 

type  INTEGER  U  range  -2*‘31 ..  2**31  -1; 


Selection  of  the  parent  of  an  integer  type 
An  integer  type  declared  by  a  declaration  of  the  form: 
type  T  is  range  L ..  R; 

is  implicitly  derived  horn  the  INTEGER  predefined  type. 


Encoding  of  integer  values 

Binary  code  is  used  to  represent  integer  values.  Negative  numbers  are  represented  using 
two’s  complement. 


Minimum  size  of  an  integer  subtype 

The  minimum  size  of  an  integer  subtype  is  the  mimmum  number  of  bits  that  is  necessary 
for  representing  the  internal  codes  of  the  subtype  values  in  normal  binary  form. 

For  a  static  subtype,  if  it  has  a  null  range  its  minimum  size  is  1.  Otherwise,  if  m  and  M  are 
the  lower  and  upper  bounds  of  the  subtype,  then  its  minimum  size  L  is  determined  as 
follows.  For  m  >  «  0,  L  is  the  smallest  positive  integer  such  that  M  <  =  2L-1.  For  m  < 
0,  L  is  the  smallest  positive  integer  that  -21^1  <  »  m  and  M  <  «  2^1  -1. 
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subtype  S  is  INTEGER  range  0 ..  7; 

~  The  minimum  size  of  S  is  3  bits. 

subtype  D  is  S  range  X ..  Y; 

"  Assuming  that  X  and  Y  are  not  static,  the  minimum  size  of 
~  D  is  3  bits  (the  same  as  the  minimum  size  of  its  type  mark  S). 


Size  of  an  integer  subtype 

The  sizes  of  the  predefined  integer  types  SHORT_SHORT_INTEGER,  _ 

SHORT_INTEGER  and  INTEGER  are  respectively  8, 16  and  32  bits. 

When  no  size  specification  is  applied  to  an  integer  type  or  to  its  first  named  subtype  (if 
any),  its  size  and  the  size  of  any  of  its  subtypes  is  the  minimum  of  8, 16  or  32  which  is 
larger  than  or  equal  to  its  minimum  size.  R)r  example: 


type  S  is  range  80 ..  100; 

••  S  is  derived  from  the  predefined  32  bit  integer,  its  size  is  8  bits, 
type  J  is  range  0 ..  255; 

-  J  is  derived  from  the  predefined  32  bit  integer  and  has  a  normal  size  of  8, 

-  therefore  has  a  size  of  8  bits. 

type  N  is  new  J  range  80 ..  100; 

"  N  is  indirectly  derived  from  the  predefined  32  bit  integer,  its  nontinal  size  is  8, 

"  therefore  its  size  is  8  bits. 

When  a  size  specification  is  applied  to  an  integer  type,  this  integer  type  and  each  of  its 
subtypes  has  the  size  specified  by  the  length  clause.  The  same  rule  applies  to  a  first 
named  subtype.  The  size  specification  must  of  course  specify  a  value  greater  than  or 
equal  to  the  minimum  size  of  the  type  or  subtype  to  which  it  applies: 

type  S  is  range  80 ..  100; 
rorS’SIZEuse32; 

-  S  is  derived  from  the  32  bit  integer  and  should  have  a  size  of  8  bits,  but  its  size  is 
••  32  bits  because  of  the  size  specification. 
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The  Alsys  compiler  fuUy  implements  size  specifications.  Nevertheless,  as  integers  are 
implemented  using  machine  integers,  the  specified  length  cannot  be  greater  than  32  bits. 


Size  of  the  objects  of  an  integer  sub^rpe 

Provided  its  size  is  not  constrained  by  a  record  component  clause  or  a  pragma  PACK,  an 
object  of  an  integer  subtype  has  the  same  size  as  its  subtype. 


Alignment  of  an  object  of  an  integer  subtype 

An  objea  of  an  integer  subtype  is  byte  aligned  if  the  size  of  the  subtype  is  less  than  or 
equal  to  8  bits,  otherwise  it  is  even  byte  aligned  if  its  size  is  smaller  than  or  equal  to  16 
bits,  otherwise  it  is  word  (4  byte)  aligned. 


43  Floating  Point  T^pes 

Predefined  floating  point  types 

There  are  three  predefined  floating  point  types  in  the  Alsys  implementation  for  SPARC 
machines: 


type  SHORT^FLOAT  is 

digits  6  nmge  -(2.0  -  2.0**(-23))*2.0**127 ..  (2.0  -  2.0**(.23))*2.0**127; 
type  FLOAT  is 

digits  6  range  -(2.0  -  i0**(-23))*2.0**127 ..  (2.0  -  2.0**(-23))*2.0**127; 
type  LONG_FLOAT  is 

digits  is  range  -(LO  -  2.0**(-5/^)*2.0**1023 ..  (2.0  -  2.0* •(-5/))*2.0**  1023; 


Selection  of  the  parent  of  a  floating  point  type 
A  floating  point  type  declared  by  a  declaration  of  the  form: 
^pe  T  is  digits  D  [range  L ..  R]; 
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is  implicitly  derived  from  a  predeflned  floating  point  type.  The  compiler  automatically 
selects  the  smallest  predeflned  floating  point  type  whose  number  of  digits  is  greater  than 
or  equal  to  D  and  which  contains  the  values  L  to  R  inclusive. 


Encoding  of  floating  point  values 

In  the  program  generated  by  the  compiler,  floating  point  values  are  represented  using 
the  EE^  standard  formats  for  single  and  double  floats. 

The  values  of  the  predefined  type  FLOAT  are  represented  using  the  single  float  format. 
The  values  of  the  predeflned  type  LONG_FLOAT  are  represented  using  the  double  float 
format  The  values  of  any  other  floating  point  type  are  represented  in  the  same  way  as 
the  values  of  the  predefined  type  from  which  it  derives,  directly  or  indirealy. 


Minimum  size  of  a  floating  point  subtype 

The  minimum  size  of  a  floating  point  subtype  is  32  bits  if  its  base  type  is  FLOAT  or  a 
type  derived  from  FLOAT;  it  is  64  bits  if  its  base  type  is  LONG_FLOAT  or  a  type 
derived  from  LONG_FLOAT. 


Size  of  a  floating  point  subtype 

The  sizes  of  the  predeflned  floating  point  types  FLOAT  and  LONG_FLOAT  are 
respectively  32  and  64  bits. 

The  size  of  a  floating  point  type  and  the  size  of  any  of  its  subtypes  is  the  size  of  the 
predeflned  type  from  which  it  derives  direaiy  or  indirectly. 

The  only  size  that  can  be  specified  for  a  floating  point  type  or  first  named  subtype  using  a 
size  spedfication  is  its  usual  size  (32  or  64  bits). 


Size  of  the  objects  of  a  floating  point  subtype 

An  object  of  a  floating  point  subtype  has  the  same  size  as  its  subtype. 
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Alignment  of  an  object  of  a  floating  point  subtype 

An  objea  of  a  floating  point  subtype  is  word  aligned  if  its  size  is  32  bits,  otherwise  it  is 
double  word  aligned. 


4.4  Fixed  Point  Types 

Small  of  a  flxed  point  type 

If  no  specification  of  small  applies  to  a  fixed  point  type,  then  the  value  of  small  is 
determined  by  the  value  of  delta  as  deflned  by  [3.5.9]. 

A  specification  of  small  can  be  used  to  impose  a  value  of  small.  The  value  of  small  is 
required  to  be  a  power  of  two. 


Predefined  fixed  point  types 

To  implement  fixed  point  types,  the  Alsys  compiler  for  SPARC  machines  uses  an 
anonymous  predefined  type  of  the  form: 


type  FIXED  32  is  delta  D  range  (-2**31-1)*S ..  2**31  *S; 
for  fixed! 2  SMALL  use  S; 

where  D  is  any  real  value  and  S  any  power  of  two  less  than  or  equal  to  D. 


Selection  of  the  parent  of  a  fi'.ed  point  type 
A  fixed  point  type  declared  by  a  declaration  of  the  form: 

type  T  is  delta  D  range  L ..  R; 
possibly  with  a  specification  of  small: 
for  TSMALL  use  S; 

is  implicitly  derived  from  a  predefined  fixed  point  type.  The  compiler  automatically 
selects  the  predefined  fixed  point  type  whose  small  and  delta  are  the  same  as  the  small 
and  delta  of  T  and  whose  range  is  the  shortest  that  includes  the  values  L  to  R  inclusive. 
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Encoding  of  fixed  point  vaiucs 

In  the  program  generated  by  the  compiler,  a  safe  value  V  of  a  Gxed  point  subtype  F  is 
represented  as  the  integer: 

V/FBASE*SMALL 


Minimum  size  of  a  Axed  point  subtype 

The  minimum  size  of  a  fixed  point  subtype  is  the  minimum  number  of  binary  digits  that 
is  necessary  for  representing  the  values  of  the  range  of  the  subtype  using  the  small  of  the 
base  type. 

For  a  static  subtype,  if  it  has  a  null  range  its  minimum  size  is  1.  Otherwise,  s  and  S  being 
the  bounds  of  the  subtype,  if  i  and  I  are  the  integer  representations  of  m  and  M,  the 
smallest  and  the  greatest  model  numbers  of  the  base  type  such  that  s  <  m  and  M  <  S, 
then  the  minimum  size  L  is  determined  as  follows.  For  i  >  =  0,  L  is  the  smallest  positive 
integer  such  that  I  <  =  2L-1.  For  i  <  0,  L  is  the  smallest  positive  integer  such  that  - 
2H  <  =  i  and  I  <  =  2^1  -1. 


type  F  is  delta  2.0  range  0.0 ..  SOO.O; 

The  minimum  size  of  F  is  8  bits. 

subtype  S  is  F  delta  16.0  range  0.0 ..  250.0; 

••  The  minimum  size  of  S  is  7  bits. 

subtype  D  is  S  range  X ..  Y; 

--  Assuming  that  X  and  Y  are  not  static,  the  minimum  size  of  D  is  7  bits 
-  (the  same  as  the  minimum  size  of  its  type  mark  S). 
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Size  of  8  fixed  point  subtype 

The  size  of  the  predefined  fixed  point  type  FIXED _32  is  32  bits. 

When  no  size  specification  is  applied  to  a  fixed  point  type  or  to  its  first  named  subtype, 
its  size  and  the  size  of  any  of  its  subtypes  is  the  minimum  of  8, 16  or  32  bits  larger  or 
equal  to  the  minimum  size.  For  example: 


type  S  is  delta  0.01  range  0.8 ..  1.0; 
~Sis8bits. 

type  F  is  delta  0.01  range  0.0 ..  20; 
-  F  is  8  bits. 


type  N  is  new  F  range  0.8 ..  1.0; 

••  N  is  8  bits. 

When  a  size  specification  is  applied  to  a  fixed  point  type,  this  fixed  point  type  and  each  of 
its  subtypes  has  the  size  specified  by  the  length  clause.  The  same  rule  applies  to  a  first 
named  subtype.  The  size  specification  must  of  course  specify  a  value  greater  than  or 
equal  to  the  minimum  size  of  the  type  or  subtype  to  which  it  applies: 

type  S  is  delta  0.01  range  0.8 ..  1.0; 
for  S’SIZE  use  32; 

--  S  is  32  bits  because  of  the  size  specification. 

type  F  is  delta  0.01  range  0.0 ..  20; 
for  FSIZE  use  8; 

--  F  is  8  bits  because  of  the  size  specification. 


Jlie  Alsys  compiler  fully  implements  size  specifications.  Nevertheless,  as  fixed  point 
objects  are  represented  using  machine  integers,  the  specified  length  cannot  be  greater 
than  32  bits. 


Size  of  the  objects  of  a  fixed  point  subtype 

Provided  its  size  is  not  constrained  by  a  record  component  clause  or  a  pragma  PACK,  an 
object  of  a  fixed  point  type  has  the  same  size  as  its  subtype. 
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Alignment  of  an  object  of  a  fixed  point  subtype 

An  objea  of  a  fixed  point  subtype  is  byte  aligned  if  its  size  is  less  than  or  equal  to  8  bits, 
otherwise  it  is  even  byte  aligned  if  its  size  is  less  than  or  equal  to  16  bits,  otherwise  it  is 
word  aligned. 


4.5  Access  lypes 

Collection  Size 

When  no  specification  of  collection  size  applies  to  an  access  type,  no  storage  space  is'' 
reserved  for  its  colleaion,  and  the  value  of  the  attribute  STORAGE_SIZE  is  then  0. 

As  described  in  [13.2],  a  specification  of  colleaion  size  can  be  provided  in  order  to 
reserve  storage  space  for  the  colleaion  of  an  access  type.  The  Alsys  compiler  fully 
implements  this  kind  of  specification. 


Encoding  of  access  values. 

Access  values  are  machine  addresses. 


Minimum  size  of  an  access  subtype 

The  minimum  size  of  an  access  subtype  is  32  bits. 

Size  of  an  access  subtype 

The  size  of  an  access  subtype  is  32  bits,  the  same  as  its  minimum  size. 

The  only  size  that  can  be  specified  for  an  access  type  using  a  size  specification  is  its  usual 
size  (32  bits). 

Size  of  an  objea  of  an  access  subtype 

An  objea  of  an  access  subtype  has  the  same  size  as  its  subtype,  thus  an  objea  of  an 
access  subtype  is  always  32  bits  long. 
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Alignment  of  an  object  of  an  access  subtype. 

An  object  of  an  access  subtype  is  always  word  aligned  except  if  a  record  representation 
clause  or  a  pragma  PACK  forces  some  other  alignment 


4,6  Task  l^pes 

Storage  for  a  task  activation 

When  no  length  clause  is  used  to  specify  the  storage  space  to  be  reserved  for  a  task 
aaivation,  the  storage  space  indicated  at  bind  time  is  used  for  this  activation. 

As  described  in  [13.2],  a  length  clause  can  be  used  to  specify  the  storage  space  for  the 
activation  of  each  of  the  tasks  of  a  given  type.  In  this  case  the  value  indicated  at  bind  time 
is  ignored  for  this  task  type,  and  the  length  clause  is  obeyed. 


Encoding  of  task  values. 

Encoding  of  a  task  value  is  not  described  here. 


Minimum  size  of  a  task  subtype 

The  minimum  size  of  a  task  subtype  is  32  bits. 

Size  of  a  task  subtype 

The  size  of  a  task  subtype  is  32  bits,  the  same  as  its  minimum  size. 

A  size  specification  has  no  effect  on  a  task  type.  The  only  size  that  can  be  speciSed  using 
such  a  length  clause  is  its  minimum  size. 

Size  of  the  objects  of  a  task  subtype 

An  object  of  a  task  subtype  has  the  same  size  as  its  subtype.  Thus  an  object  of  a  task 
subtype  is  alvrays  32  bits  long. 
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Alignment  of  an  object  of  a  task  subtype 
An  object  of  a  task  subtype  is  always  word  aligned. 


4.7  Array  Types 

Layout  of  an  array 

Each  array  is  allocated  in  a  contiguous  area  of  storage  units.  All  the  components  have 
the  same  size.  A  gap  may  exist  between  two  consecutive  components  (and  after  the  last 
one).  All  the  gaps  have  the  same  size.  - 


n 

■■■ 

n 

■■ 

Canponent  Cap  Coiponent  Cap  Component  Cap 


■  Components 

If  the  array  is  not  packed,  the  size  of  the  components  is  the  size  of  the  subtype  of  the 
components: 


type  A  is  array  (1 ..  8)  of  BOOLEAN; 

-  The  size  of  the  components  of  A  is  the  size  of  objects  of  the  type  BOOLEAN: 
--  8  bits. 

type  DECIMAL  DIGIT  is  range  0 ..  9; 
for  DECIMAL_DIGITSIZE  use  4; 

^  typeBINARY_CODED_DECIMALl8 

array  (INTEGER  range  <  >)  of  DECIMAL_DIGIT; 

-  The  size  of  the  type  DECIMAL_DIGIT  is  4  bits.  Thus  in  an  array  of 

~  type  BINARY_CODED_DECiMAL  each  component  will  be  represented  on 
~  4  bits  as  in  the  usual  BCD  represenution. 
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If  the  array  is  packed  and  its  components  are  neither  records  nor  arrays,  the  size  of  the 
components  is  the  minimum  size  of  the  subtype  of  the  components: 

type  A  Is  array  (1 ..  8)  of  BOOLEAN; 
pragma  PACK(A); 

-  The  size  of  the  components  of  A  is  the  minimum  size  of  the  type  BOOLEAN: 
-IbiL 

type  DECIMAL  DIGITis  range 0 ..  9; 
for  DECIMAL  DIGITSIZE  use  32; 
type  BINARY  j:ODED_DECIMAL  Is 

array  (INTEGER  range  <>)  of  DECIMAL  DIGIT; 
pragma  PACK(BINARY_CODED_DECIMAL);" 

"  The  size  of  the  type  DECIMAL^DIGIT  is  32  bits,  but,  as 

-  BINARY_CODED_DECIMAL  is  packed,  each  component  of  an  array  of  this 
••  type  will  be  represented  on  4  bits  as  in  the  usual  BCD  representation. 

Packing  the  array  has  no  effect  on  the  size  of  the  components  when  the  components  are 
records  or  arrays. 

■  Gaps 

If  the  components  are  records  or  arrays,  no  size  specification  applies  to  the  subtype  of 
the  components  and  the  array  is  not  packed,  then  the  compiler  may  choose  a 
represenution  with  a  gap  after  each  component;  the  aim  of  the  insertion  of  such  gaps  is 
to  optimize  access  to  the  array  components  and  to  their  subcomponents.  The  size  of  the 
gap  is  chosen  so  that  the  relative  displacement  of  consecutive  components  is  a  multiple 
of  the  alignment  of  the  subtype  of  the  components.  This  strategy  allows  each  component 
and  subcomponent  to  have  an  address  consistent  with  the  alignment  of  its  subtype: 

type  R  is 
record 

K :  INTEGER_16; » integer  is  even  byte  aligned. 

B :  BOOLEAN;  --  BOOLEAN  is  byte  aligned, 
end  record; 

-  Record  type  R  is  even  byte  aligned.  Its  size  is  24  bits, 
type  A  Is  uray  (1 ..  10)  of  R; 

-  A  gap  of  one  byte  is  inserted  after  each  component  in  order  to  respea  the 
~  alignment  of  type  R.  The  size  of  an  array  of  type  A  will  be  320  bits. 
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CoiporMnt  Cap  Coppoiwnt  Gap  Ca^ponant  Cap 


Array  of  type  A:  each  subcomponent  K  has  an  even  offset. 

If  a  size  specification  applies  to  the  subtype  of  the  components  or  if  the  array  is  packed, 
no  gaps  are  inserted:  ~  ' 


typeRis 

record 

K:  INTEGER  16; 

B :  BOOLEAN; 
end  record; 

type  A  is  array  (1 ..  10)  of  R; 
pragma  PACK(A); 

••  There  is  no  gap  in  an  array  of  type  A  because 
••  A  is  packed. 

"  The  size  of  an  objea  of  type  A  will  be  240  bits. 

type  NR  is  new  R; 
rorNR’SIZEusc24; 

type  B  is  array  (1 ..  10)  of  NR; 

~  There  is  no  gap  in  an  array  of  type  B  because 
"  NR  has  a  size  specification. 

-  -  ~  The  size  of  an  objea  of  type  B  will  be  240  bits. 


Coaponcnt  Coapenent  Conponcnt 
Array  of  type  A  or  B:  a  subcomponent  K  can  have  an  odd  offset. 
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Size  of  an  array  subQrpe 


The  size  of  an  array  subtype  is  obtained  by  multiplying  the  number  of  its  components 
the  sum  of  the  size  of  the  components  and  the  size  of  the  gaps  (if  any).  If  the  subtype  is 
unconstrained,  the  maximum  number  of  components  is  considered. 

The  size  of  an  array  subtype  cannot  be  computed  at  compile  time 

•  if  it  has  non-static  constraints  or  is  an  unconstrained  array  type  with  non-sutic 
index  subtypes  (because  the  number  of  components  can  then  only  be  determined  at 
run  time). 

■  if  the  components  are  records  or  arrays  and  their  constraints  or  the  constraints  of 
their  subcomponents  (if  any)  are  not  static  (because  the  size  of  the  components  and 
the  size  of  the  gaps  can  then  only  be  determined  at  run  time). 

As  has  been  indicated  above,  the  effect  of  a  pragma  PACK  on  an  array  type  is  to  suppress 
the  gaps  and  to  reduce  the  size  of  the  components.  The  consequence  of  packing  an  array 
type  is  thus  to  reduce  its  size. 

If  the  components  of  an  array  are  records  or  arrays  and  their  constraints  or  the 
constraints  of  their  subcomponents  (if  any)  are  not  static,  the  compiler  ignores  any 
pragma  PACK  applied  to  the  array  type  but  issues  a  warning  message.  Apart  from  this 
limitation,  array  packing  is  fully  implemented  by  the  Alsys  compiler. 

A  size  specification  applied  to  an  array  type  or  first  named  subtype  has  no  effea.  The 
only  size  that  can  be  specified  using  such  a  length  clause  is  its  usual  size.  Nevertheless, 
such  a  length  clause  can  be  useful  to  verify  that  the  layout  of  an  array  is  as  expeaed  by 
the  application. 


Size  of  the  objects  of  an  array  subtype 

The  size  of  an  objea  of  an  array  subtype  is  always  equal  to  the  size  of  the  subtype  of  the 
object 


Alignment  of  an  array  subtype 

If  no  pragma  PACK  applies  to  an  array  subtype  and  no  size  specification  applies  to  its 
components,  the  array  subtype  has  the  alignment  of  its  components. 
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If  a  pragma  PACK  applies  to  an  array  subtype  or  if  a  size  specification  applies  to  its 
components  (so  that  there  are  no  gaps),  the  alignment  of  the  array  subtype  is  the  largest 
of  word,  halfWord,  byte  or  bit  which  is  still  a  divider  of  the  size  of  the  packed  component 


Address  of  an  object  of  an  array  subtype 

Provided  its  alignment  is  not  constrained  by  a  record  represenution  clause,  the  address 
of  an  object  of  an  array  subtype  is  even  when  its  subtype  is  even  byte  aligned. 


4.8  Record  Types 

Layout  of  a  record 

Each  record  is  allocated  in  a  contiguous  area  of  storage  units.  The  size  of  a  record 
component  depends  on  its  type.  Gaps  may  exist  between  some  components. 

The  positions  and  the  sizes  of  the  components  of  a  record  type  object  can  be  controlled 
using  a  record  representation  clause  as  described  in  [13.4].  In  the  Alsys  implementation 
for  SPARC  machines  there  is  no  restriction  on  the  position  that  can  be  specified  for  a 
component  of  a  record.  If  a  component  is  of  an  enumeration,  integer  or  fixed  point  type, 
its  size  can  be  any  size  from  the  minimum  size  of  its  subtype  to  32  bits.  If  a  component  is 
of  another  class  of  type,  its  size  must  be  the  size  of  its  subtype. 

Example: 

type  INTERRUPT  MASK  b  array  (0 ..  2)  of  BOOLEAN; 
pragma  PACK(INTCRRUPT_MASK); 

--  The  size  of  INTERRUPT_MASK  is  3  bib. 

type  CONDrnON_CODE  is  0 ..  1; 

--  The  size  of  CONbrnON_CODE  is  8  bib,  ib  minimum  size  is  1  bit 

type  STATUS  BIT  b  new  BOOLEAN; 
for  STATUS_BrrSIZE  use  1; 

-  The  size  and  the  minimum  size  of  STATUS_BIT  are  1  bit 

SYSTEM  :  oonstant  :>=  0; 

USER  :  constant  1; 
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type  STATUS_REGISTER  is 
record 

T  :  STATUS  BIT; 

S  :  STATUS"BIT; 

I  :  INTERRUPT  MASK; 
X  :  CONDITION  CODE; 
N  :  CONDITION  CODE; 
Z  :  CONDITION  CODE; 
V  :  CONDITION~CODE; 
C  :  CONDmON_CODE; 
end  record; 


-Trace 

-  Supervisor 

-  Interrupt  mask 

-  Extend 

-  Negative 
-Zero 
-Overflow 
-Cany 


-  Tbis  type  can  be  used  to  map  the  status  register  of  a  MC68000  processor: 


for  STATUS_REGISTER  use 
record  at  mod  2; 

T  at  SYSTEM  range  0 ..  0; 

S  at  SYSTEM  range  2 ..  2; 

I  at  SYSTEM  ranges..?; 

X  at  USER  range  3 ..  3; 

N  at  USER  ranged..  4; 

Z  at  USER  range  S ..  5; 

V  at  USER  ranged..  6; 

C  at  USER  range  7..  7; 

end  record; 

A  record  representation  clause  need  not  specify  the  position  and  the  size  for  every 
component 

If  no  component  clause  applies  to  a  component  of  a  record,  its  size  is  the  size  of  its 
subtype.  Its  position  is  chosen  by  the  compiler  so  as  to  optimize  access  to  the 
components  of  the  record:  the  of&et  of  the  component  is  chosen  as  a  multiple  of  its 
natural  alignemnt.  Moreover,  the  compiler  chooses  the  position  of  the  component  so  as 
to  reduce  the  number  of  gaps  and  thus  the  size  of  the  record  objects. 

Because  of  these  optimizations,  there  is  no  connection  between  the  order  of  the 
components  in  a  record  type  declaration  and  the  positions  chosen  by  the  compUer  for  the 
components  in  a  record  object 
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Indirect  components 

If  the  oE^t  of  a  component  cannot  be  computed  at  compile  time,  this  oEEset  is  stored  in 
the  record  objects  at  run  time  and  used  to  access  the  component  Such  a  component  is 
said  to  be  indirect  while  other  components  are  said  to  be  direa: 


8«9(nning  af  the  record 
Coi^Ue  tfM  offset 


Coepile  tiae  offset 


Rcrt  tiae  offset 


A  direct  and  an  indirect  component 

If  a  record  component  is  a  record  or  an  array,  the  size  of  its  subtype  may  be  evaluated  at 
run  time  and  may  even  depend  on  the  discriminants  of  the  record.  We  will  call  these 
components  dynamic  components: 

Example: 

type  DEVICE  is  (SCREEN,  PRINTER); 
type  COLOR  b  (GREEN,  RED,  BLUE); 

^  SERIES  b  «rniy  (POSITIVE  range  <>)  of  INTEGER; 
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typ¥  GRAPH  (L :  NATURAL)  Is 
record 

X:SERIES(1  ..L); -The  size  of  X  depends  on  L 
Y :  SERIES(1  „  L);  -  The  size  of  Y  depends  on  L 
end  record; 

Q :  POSITIVE; 

type  PICTURE  (N :  NATURAL;  D :  DEVICE)  Is 
record 

F :  GRAPH(N);  -  The  size  of  F  depends  on  N  - 

S :  GRAPH(Q);  -  The  size  of  S  depends  on  Q 

caseDis 

when  SCREEN  =  > 

C ;  COLOR; 
frtien  PRINTER  => 
null; 
end  case; 
end  record; 

Any  component  placed  after  a  dynamic  component  has  an  offset  which  cannot  be 
evaluated  at  compile  time  and  is  thus  indirect  In  order  to  minimize  the  number  of 
indirea  components,  the  compiler  groups  the  dynamic  components  together  and  places 
them  at  the  end  of  the  record: 
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Thanks  to  this  strategy,  the  only  indirect  components  are  dynamic  components.  But  not 
all  dynamic  components  are  necessarily  indirect:  if  there  are  dynamic  components  in  a 
component  list  which  is  not  followed  by  a  variant  part,  then  exactly  one  dynamic 
component  of  this  list  is  a  direa  component  because  its  o&et  can  be  computed  at 
compilation  time  (the  only  dynamic  components  that  are  direa  components  are  in  this 
situation): 
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Beginning  of  the  record 
Coepile  tiae  offset 


-  Coapile  tiae  offset 
Size  depe<vdent  on  discriainant  L 
■  Run  tiae  offset 
Size  dependent  on  discriainant  L 


The  record  tvpc  GRAPH:  the  dynamic  component  X  is  a  direct  component. 

The  ofEset  of  an  indirect  component  is  always  expressed  in  storage  units. 

The  space  reserved  for  the  ofE&et  of  an  indirect  component  must  be  large  enough  to  store 
the  size  of  any  value  of  the  record  type  (the  maximum  potential  o(&et).  The  compiler 
evaluates  an  upper  bound  MS  of  this  size  and  treats  an  offset  as  a  component  having  an 
anonymous  integer  type  whose  range  is  0 ..  MS. 

If  C  is  the  name  of  an  indirect  component,  then  the  offset  of  this  component  can  be 
denoted  in  a  component  clause  by  the  implementation  generated  name  COFPSET. 


Implicit  components 

In  some  circumstances,  access  to  an  objea  of  a  record  type  or  to  its  components  involves 
computing  information  which  only  depends  on  the  discriminant  values.  To  avoid  useless 
recomputation  the  compiler  stores  this  information  in  the  record  objects,  updates  it 
when  the  values  of  the  discriminants  are  modified  and  uses  it  when  the  objects  or  its 
components  are  accessed.  This  information  is  stored  in  special  components  called 
implicit  components. 
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An  implidt  component  may  contain  information  which  is  used  when  the  record  objea  or 
several  of  its  components  are  accessed.  In  this  case  the  component  will  be  included  in  any 
record  object  (the  implidt  component  is  considered  to  be  declared  before  Lny  variant 
part  in  the  record  type  declaration).  There  can  be  two  components  of  this  kind;  one  is 
caUed  RECORD_SIZE  and  the  other  VARIANT_1NDEX. 

On  the  other  hand  an  implidt  component  may  be  used  to  access  a  given  record 
component.  In  that  case  the  implidt  component  exists  whenever  the  record  component 
exists  (the  implidt  component  is  considered  to  be  declared  at  the  same  place  as  the 
record  component).  Components  of  this  kind  are  called  ARRAY  DESCRIPTORS  or 
RECORD_DESCRIPTORs. 

.  RECORDJIZE 

This  implidt  component  is  created  by  the  compiler  when  the  record  type  has  a  variant 
part  and  its  discriminants  are  defaulted.  It  contains  the  size  of  the  storage  space 
necessary  to  store  the  current  value  of  the  record  object  (note  that  the  storage  effectively 
allocated  for  the  record  object  may  be  more  than  this). 

The  value  of  a  RECORD^SIZE  component  may  denote  a  number  of  bits  or  a  number  of 
storage  units.  In  general  it  denotes  a  number  of  storage  units,  but  if  any  component 
clause  spedfies  that  a  component  of  the  record  type  has  an  offset  or  a  size  which  cannot 
be  expressed  using  storage  units,  then  the  value  designates  a  number  of  bits. 

The  implidt  component  RECORD_SIZE  must  be  large  enough  to  store  the  maximum 
size  of  any  value  of  the  record  type.  The  compiler  evaluates  an  upper  bound  MS  of  this 
size  and  then  considers  the  implidt  component  as  having  an  anonymous  integer  type 
whose  range  is  0 ..  MS. 

If  R  is  the  name  of  the  record  type,  this  implidt  component  can  be  denoted  in  a 
component  clause  by  the  implementation  generated  name  R’RECORD_SlZE. 

.  VARIANT  JNDEX 

This  implidt  component  is  created  by  the  compiler  when  the  record  type  has  a  variant 
part  It  indicates  the  set  of  components  that  are  present  in  a  record  value.  It  is  used  when 
a  discriminant  check  is  to  be  done. 

Component  Usts  that  do  not  contain  a  variant  part  are  numbered.  These  numbers  are  the 
possible  values  of  the  implidt  component  VARIANT_INDEX. 
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Example: 


type  VEHICLE  b  (AIRCRAFT,  ROCKET,  BOAT,  CAR); 

type  DESCRIPTION  (KIND :  VEHICLE  :=  CAR)  b 
record 

SPEED :  INTEGER; 
caseKINDb 

when  AIRCRAFT  |  CAR  => 

WHEELS :  INTEGER; 
caseKINDb 

when  AIRCRAFT  =  >  -  1 

WINGSPAN :  INTEGER; 
when  others  =  >  -  2 

null; 

end  case; 

when  BOAT  =  >  ~  3 

STEAM  :  BOOLEAN; 
when  ROCKET  =  >  -  4 

STAGES :  INTEGER; 
end  case; 
end  record; 

The  value  of  the  variant  index  indicates  the  set  of  components  that  are  present  in  a 
record  value: 


Variant  Indax 

S€t 

1 

(KINO,  SPEED,  WHEELS,  WINGSPAN} 

2 

(KINO,  SPEED,  WHEELS} 

3 

(KIND,  SPEED,  STEAM} 

4 

(KINO,  SPEED,  STAGES} 

A  comparison  between  the  variant  index  of  a  record  value  and  the  bounds  of  an  interval 
is  enough  to  check  that  a  given  component  is  present  in  the  value: 
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Caipon«nt 

Interval 

KIND 

SPEED 

-- 

UHEELS 

1  ..  2 

1  ..  1 

STEAM 

STAGES 

The  implicit  component  VARIANT_INDEX  must  be  large  enough  to  store  the  number 
V  of  component  lists  that  don’t  contain  variant  parts.  The  compiler  treats  this  implicit 
component  as  having  an  anonymous  integer  type  whose  range  is  1 ..  V.  ~ 

If  R  is  the  name  of  the  record  type,  this  implicit  component  can  be  denoted  in  a 
component  clause  by  the  implemenution  generated  name  R’VAR1ANT_INDEX. 

.  ARRAY_DESCRlPTOR 

An  implicit  component  of  this  kind  is  associated  by  the  compiler  with  each  record 
component  whose  subtype  is  an  anonymous  array  subtype  that  depends  on  a  discriminant 
of  the  record.  It  contains  information  about  the  component  subtype. 

The  structure  of  an  implicit  component  of  kind  ARRAY_DESCRIPTOR  is  not 
described  in  this  documentation.  Nevertheless,  if  a  programmer  is  interested  in 
specifying  the  location  of  a  component  of  this  kind  using  a  component  clause,  he  can 
obtain  the  size  of  the  component  using  the  ASSEMBLY  parameter  in  the  COMPILE 
command. 

The  compiler  treats  an  implicit  component  of  the  kind  ARRAY_DESCRIPTOR  as 
having  an  anonymous  array  type.  If  C  is  the  name  of  the  record  component  whose 
subtype  is  described  by  the  array  descriptor,  then  this  implicit  component  can  be  denoted 
in  a  component  clause  by  the  implementation  generated  name 
CARRAY_DESCRIPTOR. 

.  RECORD_DESCRIPTOR 

An  implicit  component  of  this  kind  is  associated  by  the  compiler  with  each  record 
component  whose  subtype  is  an  anonymous  record  subtype  that  depends  on  a 
discriminant  of  the  record.  It  contains  information  about  the  component  subtype. 
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The  stni^ure  of  an  implicit  component  of  kind  RECORD_DESCRIPTOR  is  not 
described  in  this  documenution.  Nevertheless,  if  a  programmer  is  interested  in 
specifying  the  location  of  a  component  of  this  kind  using  a  component  clause,  he  can 
obtain  the  size  of  the  component  using  the  ASSEMBLY  parameter  in  the  COMPILE 
command. 

The  compiler  treats  an  implicit  component  of  the  kind  RECORD_DESCRIPTOR  as 
having  an  anonymous  array  type.  If  C  is  the  name  of  the  record  component  whose 
subtype  is  described  by  the  record  descriptor,  then  this  implicit  component  can  be 
denoted  in  a  component  clause  by  the  implementation  generated  name 
CRECORD_DESCRIPTOR.  _  . 


Suppresston  of  implidt  components 

The  Alsys  implementation  provides  the  capability  of  suppressing  the  implidt 
components  RECORD_SIZE  and/or  VARIANT_INDEX  from  a  record  type.  This  can 
be  done  using  an  implementation  defined  pragma  called  IMPROVE.  The  syntax  of  this 
pragma  is  as  follows: 

pragma  IMPROVE  ( TIME  |  SPACE ,  [ON  *  >)  simple_name ); 

The  frrst  argument  spedfies  whether  TIME  or  SPACE  is  the  primary  criterion  for  the 
choice  of  the  representation  of  the  record  type  that  is  denoted  by  the  second  argument. 

If  TIME  is  spedfied,  the  compiler  inserts  implidt  components  as  described  above.  If  on 
the  other  hand  SPACE  is  spedfied,  the  compiler  only  inserts  a  VAR1ANT_INDEX  or  a 
RECORD_SIZ£  component  if  this  component  appears  in  a  record  representation 
clause  that  applies  to  the  record  type.  A  record  representation  clause  can  thus  be  used  to 
keep  one  implicit  component  while  suppressing  the  other. 

A  pragma  IMPROVE  that  applies  to  a  given  record  type  can  occur  anywhere  that  a 
representation  clause  is  allowed  for  this  type. 


Size  of  a  record  subtype 

Unless  a  component  clause  spedfres  that  a  component  of  a  record  type  has  an  offret  or  a 
size  which  cannot  be  expressed  using  storage  units,  the  size  of  a  record  subtype  is 
rounded  up  to  the  a  whole  number  of  storage  units. 
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The  size  of  a  constrained  record  subtype  is  obtained  by  adding  the  sizes  of  its 
components  and  the  sizes  of  its  gaps  (if  any).  This  size  is  not  computed  at  compile  time 

■  when  the  record  subtype  has  non-static  constraints, 

■  when  a  component  is  an  array  or  a  record  and  its  size  is  not  computed  at  compile 
time. 

The  size  of  an  unconstrained  record  subtype  is  obtained  by  adding  the  sizes  of  the 
components  and  the  sizes  of  the  gaps  (if  any)  of  its  largest  variant  If  the  size  of  a 
component  or  of  a  gap  cannot  be  evaluated  exactly  at  compile  time  an  upper  bound  of 
this  size  is  used  by  the  compiler  to  compute  the  subtype  size. 

A  size  specification  applied  to  a  record  type  or  first  named  subtype  has  no  effect  The 
only  size  that  can  be  specified  using  such  a  length  clause  is  its  usual  size.  Ne\’ert'.eless, 
such  a  length  clause  can  be  useful  to  verify  that  the  layout  of  a  record  is  as  expeaed  by 
the  application. 


Size  of  an  object  of  a  record  subtype 

An  objea  of  a  constrained  record  subtype  has  the  same  size  as  its  subtype. 

An  object  of  an  unconstrained  record  subtype  has  the  same  size  as  its  subtype  if  this  size 
is  less  than  or  equal  to  8  kb.  If  the  size  of  the  subtype  is  greater  than  this,  the  object  has 
the  size  necessary  to  store  its  current  value;  storage  space  is  allocated  and  relea^  as  the 
discriminants  of  the  record  change. 


Alignment  of  a  record  subtype 

When  no  record  represenution  clause  applies  to  its  base  type,  a  record  subtype  takes  the 
stronger  alignment  of  its  components. 

When  a  record  representation  clause  that  does  not  contain  an  alignment  clause  applies 
to  its  base  type,  the  subtype  alignment  is  the  largest  of  word,  halfword,  byte  or  bit  which 
is  a  divider  of  the  position  of  one  of  the  components. 

When  a  record  representation  clause  that  conuins  an  alignment  clause  applies  to  its  base 
type,  a  record  subtype  has  an  alignment  that  obeys  the  alignment  clause,  an  alignment 
clause  can  specify  that  a  record  type  is  byte,  halfWord  or  word  aligned. 
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Address  of  an  object  of  a  record  subtype 

Provided  its  alignment  is  not  constrained  by  a  representation  clause,  the  address  of  an 
objea  of  a  record  subtype  is  even  when  its  subtype  is  even  byte  aligned. 
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CHAPTERS 


IMPLEMENTATION-DEPENDENT  COMPONENTS 


The  following  forms  of  implemenution-generated  names  [13.4(g)]  are  used  to  denote 
implementation-dependent  record  components,  as  described  in  S^ion  4.8  in  the 
paragraph  on  indirect  and  implicit  components: 


COFFSET 
R’RECORD  SIZE 
R’VARIANT  INDEX 
R’ARRAY  DESCRIPTORS 
R’RECORD  DESCRIPTORS 


where  C  is  the  name  of  a  record  component  and  R  the  name  of  a  record  type. 
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CHAPTER  6 


ADDRESS  CLAUSES 


An  address  clause  can  be  used  to  specify  the  address  of  an  object,  a  program  unit  or  an 
entry. 


6.1  Address  Clauses  for  Objects 

An  address  clause  can  be  used  to  specify  an  address  for  an  object  as  described  in  [13.S]. 
When  such  a  clause  applies  to  an  object  no  storage  is  allocated  for  it  in  the  program 
generated  by  the  compiler.  The  program  accesses  the  objea  by  using  the  address 
specified  in  the  clause. 

An  address  clause  is  not  allowed  for  task  objects,  for  unconstrained  records  whose  size  is 
greater  than  8  kb,  or  for  a  constant 

Note  that  the  function  SYSTEM. VALUE,  defined  in  the  package  SYSTEM,  is  available  to 
convert  a  STRING  value  into  a  value  of  type  SYSTEMADDRESS,  also,  the  IMPORT 
attribute  is  available  to  provide  the  address  of  an  external  symbol.  (Refer  to  Chapter  3 
and  section  2.3) 

6.2  Address  Clauses  for  Program  Units 

Address  clauses  for  program  units  are  not  implemented  in  the  current  version  of  the 
compiler. 


63  Address  Clauses  for  Entries 

An  address  clause  may  be  used  to  associate  an  entry  with  a  UNIX  signal.  {Sec  AppBcation 
Devel<^>er’s  Guide  for  detailed  information.) 


Address  Clauses 
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CHAPTER? 


UNCHECKED  CONVERSIONS 


Unchecked  type  conversions  are  described  in  [13.10.2].  The  following  restrictions  apply 
to  their  use. 


Unconstrained  arrays  are  not  allowed  as  target  types.  Unconstrained  record  types 
without  defaulted  discriminants  are  not  allowed  as  target  types.  Access  types  to 
unconstrained  arrays  are  not  allowed  as  urget  or  source  types.  Note  also  that 
UNCHECKED_CONVERSION  cannot  be  used  for  an  access  to  an  unconstrained 
string. 

However,  if  the  source  and  the  urget  types  are  each  scalar  or  access  types,  the  sizes  of  the 
objects  of  the  source  and  target  types  must  be  equal. 

If  a  composite  type  is  used  either  as  source  type  or  as  urget  type  this  restriction  on  the 
size  does  not  apply. 

If  the  source  and  the  urget  types  are  each  of  scalar  or  access  type  or  if  they  are  both  of 
composite  type,  the  effect  of  the  function  is  to  return  the  operand. 

In  other  cases  the  effea  of  unchecked  conversion  can  be  considered  as  a  copy: 

■  If  an  unchecked  conversion  is  achieved  of  a  scalar  or  access  source  type  to  a 
composite  urget  type,  the  result  of  the  function  is  a  copy  of  the  source  operand. 

The  result  has  the  size  of  the  source. 

■  If  an  unchecked  conversion  is  achieved  of  a  composite  source  type  to  a  scalar  or 
access  urget  type,  the  result  of  the  function  is  a  copy  of  the  source  operand.  The 
result  has  the  size  of  the  target 
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CHAPTERS 


INPUT-OUTPUT  CHARACTERISTICS 


In  this  part  of  the  Appendix  the  implementation-specific  aspects  of  the 
input-output  system  are  described. 


8.1  Introduction 

In  Ada,  input-output  operations  are  considered  to  be  performed  on  objects  of 
a  certain  file  type  rather  than  being  performed  directly  on  external  files.  An 
external  file  is  anything  external  to  the  program  that  can  produce  a  value  to 
be  read  '.eive  a  value  to  be  written.  Values  transferred  for  a  given  file 
must  be  u.  one  type. 

Generally,  in  Ada  documentation,  the  term  file  refers  to  an  object  of  a 
certain  file  type,  whereas  a  physical  manifestation  is  known  as  an  external 
file.  An  exter^  file  is  characterized  by 

■  itsNAME,  which  is  a  string  defining  a  legal  path  name  under  the  current 
version  of  the  operating  system 

■  its  FORM ,  which  gives  implementation-dependent  information  on  file 
characteristics. 

Both  the  NAME  and  the  FORM  appear  e]q>licitly  as  parameters  of  the  Ada 
procedures  CREATE  andOPEN .  Though  a  file  is  an  object  of  a  certain  file 
type,  ultimately  the  object  has  to  correspond  to  an  external  file.  Both  CREATE 
andOPEN  associate  a  NAME  of  an  external  file  (of  a  certain  FORM)  with  a 
program  file  object. 

Ada  mput-output  operations  are  provided  by  means  of  standard  packages 

(114)): 
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SEQlJENTIAL_IO  A  generic  package  for  sequential  files  of  a  single 
element  type. 

DlR£CT_IO  A  generic  package  for  direct  (random)  access  files. 

TEXT  lO  A  generic  package  for  human-readable  files  (text, 

ASai). 

(Please  note  that  trying  to  apply  TEXT_IO.NAME  or 
TEXTJO.FORM  toSTANDARD_INPUT  or 
STANDARD_OUTPUT  will  raise  USE_ERROR .  Though  U 
may  surprise  the  user,  [14.4(5)]  allows  this  behavior.) 

IO_EXCEPTIONS  A  package  which  defines  the  exceptions  needed  by  the 
above  three  packages. 

The  generic  package  LOW_LEVEL_IO  is  not  implemented  in  this  version. 

The  upper  bound  for  index  values  in  DIRECTJO  and  for  line,  column  and 
page  numbers  inTEXTJO  is  given  by 

COUNTLAST  =  2**31  -1 

The  upper  bound  for  field  widths  inTEXT^IO  is  pven  by 
FTELD’L^ST  =  255 

8.2  The  Parameter  FORM 

The  parameter  FORM  of  both  the  procedures  CREATE  and  OPEN  in  Ada 
spedfies  the  characteristics  of  the  external  Tile  involved. 

The  procedure  CREATE  establishes  a  new  external  file,  of  a  given  NAME  and 
FORM,  and  associates  it  with  a  specified  program  file  object.  The  external  file 
is  created  (and  the  file  object  set)  with  a  specified  (or  default)  file  mode.  If 
the  external  file  already  exists,  the  file  will  be  erased.  The  exception 
USE_ERROR  is  raised  if  the  file  mode  isIN_FILE. 
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Example:. 


CREATE(F,  OUT  FILE,  NAME  *>  'MY  FILE*, 

FORM»> 

•WORLD  =  >  READ,  OWNER  =  >  READ_WRITE*); 

The  procedure  OPEN  associates  an  existing  external  file,  of  a  given  NAME 
and  FORM ,  with  a  specified  program  file  c^ecL  The  procedure  also  sets  the 
current  file  mode.  If  there  is  an  inadmlssihte  change  of  mode,  then  the 
exception  USE_ERROR  is  raised. 

The  parameter  FORM  is  a  string,  formed  from  a  list  of  attributes,  with  -  '■ 

attributes  separated  by  commas.  The  string  is  not  case  sensitive  (so  that,  for 
example,  HERE  and  here  are  treated  alike).  ^RM  attributes  are  distinct 
from  Ada  attributes.)  The  attributes  specify: 

■  File  protection 

■  File  sharing 

■  File  struaure 

■  Buffering 

■  Appending 
•  Blocking 

■  Terminal  input 

The  general  form  of  each  attribute  is  a  keyword  followed  by  =  >  and  then  a  qualifier.  The 
anow  and  qualifier  may  sometimes  be  omitted.  The  format  for  an  attribute  specifier  is 
thus  either  of 

-  KEYWORD 

KEYWORD  «  >  QUAUFIER 

We  will  discuss  each  attribute  in  turn. 
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File  Protectioa 


These  attributes  are  only  meaningful  for  a  call  to  the  procedure  CREATE . 

nie  protection  involves  two  independent  classifications.  The  first 
classification  is  related  to  who  may  access  the  file  and  is  specified  by  the 
keywords: 

OWNER  Only  the  owner  of  the  directory  may  access  this  file. 

GROUP  Only  the  members  of  a  predefined  group  of  users  may  ao^ 

this  file. 

WORLD  Any  user  may  access  this  file. 

For  each  type  of  user  who  may  access  a  file  there  are  various  access  nghts;  and  this  forms 
the  basis  for  the  second  classification.  In  general,  there  are  four  types  of  access  right, 
specified  by  the  qualifiers: 

READ  The  user  may  read  from  the  external  file. 

WRITE  The  user  may  write  to  the  external  file. 

EXECUTE  The  user  may  execute  programs  stored  in  the  external  file. 

NONE  The  user  has  no  access  rights  to  the  external  file.  (This  access 

right  negates  any  prior  privileges.) 

More  than  one  access  right  may  be  relevant  for  a  particular  file,  in  which  case  the 
qualifiers  are  linked  with  underscores  (  _). 

For  example,  suppose  that  the  WORLD  may  execute  a  program  in  an  external  file,  but 
only  the  OWNER  may  modify  the  file. 

WORLD  => 

EXECUTE. 

OWNER  -  > 

READ  WRITE  EXECUTE 
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Repetition  of  the  same  qualifier  within  the  attributes  is  illegal: 
WORLD 

EXECUTEJXECUTE.  -NOT  legal 

but  repetition  of  the  entire  attribute  is  allowed: 

WORLD 

EXECUTE, 

WORLD  => 

EXECUTE  -Legal 


File  Sharing 

An  external  file  can  be  shared,  which  means  associated  simultaneously  with  several 
logical  nie  objects  created  by  the  procedures  OPEN  and  CREATE. 

The  file  sharing  attribute  may  restrict  or  suppress  this  capability  by  specifying  one  of  the 
following  access  modes: 

NOTJSHARED  Exclusive  access  -  no  other  logical  file  may  be  associated 

with  the  external  file 

SHARED  =  >  READERS  Only  logical  files  opened  with  mode  IN  are  allowed 

SHARED  =  >  SINGLE  JVRTTER 

Only  logical  files  opened  with  mode  IN  and  at  most  one 
with  mode  INOUT  or  OUT  are  allowed 

SHARED  -  >  ANY  No  restriction 

The  exception  USE_ERROR  is  raised  if,  for  an  external  file  already  associated  with  an 
Ada  file  object 

■  a  further  OPEN  or  CREATE  specifies  a  file  sharing  attribute  different  from  the 
current  one 

■  a  further  OPEN,  CREATE  or  RESET  violates  the  conditions  imposed  by  the  current 
file  sharing  attribute. 
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The  restriaions  imposed  by  the  file  sharing  attribute  disappear  when  the  last  logical  file 
object  linked  to  the  external  file  is  closed. 

The  file  sharing  attribute  provides  control  over  multiple  accesses  within  the  program  to  a 
given  external  file.  This  control  does  not  extend  to  the  whole  system. 

The  deEault  value  for  the  file  sharing  attribute  is  SHARED  =  >  ANY. 


File  Structure 

(a)  Text  Files  -  ' 

There  is  no  FORM  attribute  to  define  the  structure  of  text  files. 

A  text  file  consists  of  a  sequence  of  bytes  holding  the  ASCII  codes  of  charaaers. 

The  representation  of  Ada  terminators  depends  on  the  file’s  mode  (IN  or  OUT)  and 
whether  it  is  associated  with  a  terminal  device  or  a  mass  storage  file;  the  terminators  are 
implicit  in  some  cases,  the  characters  present  explicitly  being  as  follows; 

•  Mass  storage  files  and  terminal  device  with  mode  OUT 

end  of  line:  ASCII.LF 

end  of  page;  ASCII.LF  ASCII.FF 

end  of  file;  ASCIl.EOT 

The  file  length  determines  implicit  page  and  file  terminators  at  the  end. 

■  Terminal  device  with  mode  IN 

end  of  line;  ASCI1.LF 

end  of  page;  ASCII.FF 

end  of  file;  The  UNIX  default  value  (for  instance 

ASCII.EOT) 

The  FF  implies  a  line  terminator;  the  end  of  file  character  implies  both  line  and 
page  terminators. 
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(b)  Binary  Files 

TV^o  FORM  attributes,  RECORD JI2E  and  RECORDJJNIT,  control  the  structure  of 
binary  files. 

A  binary  file  can  be  viewed  as  a  sequence  (sequential  access)  or  a  set  (direa  access)  of 
consecutive  RECORDS. 

The  structure  of  such  a  record  is: 

(HEADER!  OBJECT  [ UNUSED_PART ] 

and  it  is  formed  from  up  to  three  items: 

■  An  OBJECT  with  exactly  the  same  binary  representation  as  the  Ada  object  in  the 
executable  program,  possibly  including  an  object  descriptor 

■  A  HEADER  consisting  of  two  fields  (each  of  32  bits): 

•  the  length  of  the  objea  in  bytes  (except  for  the  length  of  unconstrained  arrays 
which  is  in  bits) 

•  the  length  of  the  descriptor  in  bytes  which  is  always  set  to  0 

■  An  UNUSED.PART  of  variable  size  to  permit  full  control  of  the  record’s  size. 

The  HEADER  is  implemented  only  if  the  actual  parameter  of  the  instantiation  of  the 
input-output  package  is  unconstrained. 

The  file  structure  attributes  take  the  form: 

RECORDJSIZE  =  >  sizejnjiytes 

RECORDJJNIT  =  >  sizejnj/ytes 

Their  meaning  depends  on  the  objea's  type  (constrained  or  not)  and  the  file  access  mode 
(sequential  or  direa  access): 
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a)  If  the  object’s  type  is  constrained: 

-  The  attribute  RECORD JJNFT  is  illegal 

-  If  the  attribute  RECORD_SIZE  is  omitted,  no  UNUSED_PART  will  be 
implemented:  the  default  RECORDJ5IZE  is  the  object’s  size 

-  If  present,  the  attribute  RECORDJSIZE  must  specify  a  record  size  greater 
than  or  equal  to  the  objea's  size,  otherwise  the  exception  USE_ERROR  will 
be  raised 

b)  If  the  objea’s  type  is  unconstrained  and  the  file  access  mode  is  direct: 

-  The  attribute  RECORDJJNIT  is  illegal 

-  The  attribute  RECORD _SIZ£  has  no  default  value,  and  if  it  is  not  specified, 
USE_ERROR  will  be  raised 

-  An  attempt  to  input  or  output  an  objea  larger  than  the  given  RECORD_SIZE 
will  raise  the  exception  DATA.ERROR 

c)  If  the  objea’s  type  is  unconstrained  and  the  file  access  mode  is  sequential: 

•  The  attribute  RECORDJSIZE  is  illegal 

-  The  default  value  of  the  attribute  RECORDJJNIT  is  1  (byte) 

•  The  record  size  will  be  the  smallest  multiple  of  the  specified  (or  default) 
RECORDJJNIT  that  holds  the  objea  and  its  length.  This  is  the  only  case 
where  records  of  a  file  may  have  different  sizes. 
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Buffering 

The  buffer  size  can  be  spedfled  by  the  attribute 
BUFFERJSIZE  =»  >  sizejnjbyta 
A  buffer  size  of  0  means  no  buffering. 

The  default  value  for  buffer  size  depends  on  the  type  of  the  external  file  and  on  the  file 
access  mode,  as  follows: 

■  If  the  external  file  is  a  'regular'  UNIX  mass  storage  file,  the  default  buffer  size  is  the 
system’s  Input-Output  block  size  (typically  1024  or  2048).  For  other  types  of  UNIX 
files  (directories,  device  files,  named  pipes),  the  default  buffer  size  is  0  (no 
buffering). 

■  For  a  file  used  in  direa  access  mode  or  the  STANDARD_OUTPUT  file,  the  default 
buffer  size  is  in  any  case  0. 


Appending 

Only  to  be  used  with  the  procedure  OPEN,  the  format  of  this  attribute  is  simply 
APPEND 

and  it  means  that  any  output  will  be  placed  at  the  end  of  the  named  external  file. 

In  normal  circumsunces,  when  an  external  file  is  opened,  an  index  is  set  which  points  to 
the  beginning  of  the  file.  If  the  attribute /4PF£NZ>  is  present  for  a  sequential  or  for  a  text 
file,  then  data  transfer  will  commence  at  the  end  of  the  file.  For  a  direa  access  file,  the 
value  of  the  index  is  set  to  one  more  than  the  number  of  records  in  the  external  file. 

This  attribute  is  not  applicable  to  terminal  devices. 

USE_ERROR  is  raised  when  the  file  mode  is  IN_FIL£. 

USE  ERROR  is  raised  if  the  file  size  is  not  a  multiple  of  RECORD  SIZE  or 
RECbRD_UNIT. 
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Blocking 

This  attribute  has  two  alternative  forms: 
BLOCKING, 


or 


NON_BLOCKING. 

This  attribute  specifies  the  desired  behavior  of  the  input-output  system  at  any  moment 
that  a  request  for  dau  transfer  cannot  be  fulfliled.  The  stoppage  may  be  due,  for  . 
example,  to  the  unavailability  of  data,  or  to  the  unavailability  of  the  external  Gle  device. 

NON_BLOCKING 

If  this  attribute  is  set,  then  the  task  that  ordered  the  data  transfer  is  suspended  • 
meaning  that  other  tasks  can  execute.  The  suspended  task  is  kept  in  a  ‘ready’  state, 
together  with  other  tasks  in  a  ready  state  at  the  same  priority  level  (that  is,  it  is 
rescheduled). 

When  the  suspended  task  is  next  scheduled  to  run,  the  dau  transfer  request  is 
reaaivated  If  ready,  the  transfer  is  activated,  otherwise  the  rescheduling  is 
repeated.  Control  returns  to  the  user  program  after  completion  of  the  data  transfer. 

BLOCKING 

In  this  case  the  task  waits  until  the  dau  transfer  is  complete,  and  all  other  tasks  are 
suspended  (or  ‘blocked’).  The  system  is  busy  waiting. 

The  default  for  this  attribute  depends  on  the  aaual  program:  it  is  BLOCKING  for 
programs  without  task  declarations  and  NONJBLOCKING  for  a  program  conuining 
tasks. 
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Terminal  input 

This  attribute  takes  one  of  two  alternative  forms: 

TERMINALJNPUT  *  >  UNES, 

TERMINALJNPUT  *  >  CHARACTERS, 

Terminal  input  is  normally  processed  in  units  of  a  line  at  a  time,  where  a  line  is  delimited 
by  a  special  character.  A  process  attempting  to  read  from  the  terminal  as  an  external  file 
will  be  suspended  until  a  complete  line  has  been  typed.  At  that  time,  the  outstanding 
read  call  (and  possibly  also  later  calls)  will  be  satisfied. 

The  first  option  specifies  line-at-a-time  data  transfer,  which  is  the  default  case. 

The  second  option  means  that  dau  transfer  is  character  by  character,  and  so  a  complete 
line  does  not  have  to  be  entered  before  the  read  request  can  be  satisfied.  For  this  option 
the  BUFFER_S1ZE  must  be  zero. 

The  attribute  TERMINALJNPUT  is  only  applicable  to  terminal  devices. 
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